undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
d74bb308fa
git-commit-vandalism/gitk-git/gitk

11314 lines
305 KiB
Plaintext
Raw Normal View History

Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
Use "$@" rather than "${1+$@}" when invoking wish.
2005-09-27 02:29:41 +02:00
exec wish "$0" -- "$@"
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
# Copyright © 2005-2008 Paul Mackerras. All rights reserved.
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
# This program is free software; it may be used, copied, modified
# and distributed under the terms of the GNU General Public Licence,
# either version 2, or (at your option) any later version.
[PATCH] gitk: Use GIT_DIR where appropriate. Some places assumed .git is the GIT_DIR, resulting heads and tags not showing when it was run like "GIT_DIR=. gitk --all". This is not a contrived example --- I rely on it to verify my private copy of git.git repository before pushing it out. Define a single procedure "gitdir" and use it. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-07-28 09:28:44 +02:00
proc gitdir {} {
global env
if {[info exists env(GIT_DIR)]} {
return $env(GIT_DIR)
} else {
[PATCH] Make gitk work when launched in a subdirectory Make gitk use git-rev-parse --git-dir to find the repository. Signed-off-by: Peter Baumann <siprbaum@stud.informatik.uni-erlangen.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-01-09 15:30:19 +01:00
return [exec git rev-parse --git-dir]
[PATCH] gitk: Use GIT_DIR where appropriate. Some places assumed .git is the GIT_DIR, resulting heads and tags not showing when it was run like "GIT_DIR=. gitk --all". This is not a contrived example --- I rely on it to verify my private copy of git.git repository before pushing it out. Define a single procedure "gitdir" and use it. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-07-28 09:28:44 +02:00
}
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
# 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
# run before X event handlers, so reading from a fast source can
# make the GUI completely unresponsive.
proc run args {
gitk: Allow safely calling nukefile from a run queue handler Originally dorunq assumed that the queue entry remained first in the queue after the script eval, and blindly removed it. However, if the handler calls nukefile, it may not be the case anymore, and a random queue entry gets dropped instead. This makes dorunq remove the entry before calling the script, and adds a global variable to allow other functions to determine if they are called from within a dorunq handler. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-09 12:41:50 +02:00
global isonrunq runq currunq
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set script $args
if {[info exists isonrunq($script)]} return
gitk: Allow safely calling nukefile from a run queue handler Originally dorunq assumed that the queue entry remained first in the queue after the script eval, and blindly removed it. However, if the handler calls nukefile, it may not be the case anymore, and a random queue entry gets dropped instead. This makes dorunq remove the entry before calling the script, and adds a global variable to allow other functions to determine if they are called from within a dorunq handler. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-09 12:41:50 +02:00
if {$runq eq {} && ![info exists currunq]} {
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
after idle dorunq
}
lappend runq [list {} $script]
set isonrunq($script) 1
}
proc filerun {fd script} {
fileevent $fd readable [list filereadable $fd $script]
}
proc filereadable {fd script} {
gitk: Allow safely calling nukefile from a run queue handler Originally dorunq assumed that the queue entry remained first in the queue after the script eval, and blindly removed it. However, if the handler calls nukefile, it may not be the case anymore, and a random queue entry gets dropped instead. This makes dorunq remove the entry before calling the script, and adds a global variable to allow other functions to determine if they are called from within a dorunq handler. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-09 12:41:50 +02:00
global runq currunq
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
fileevent $fd readable {}
gitk: Allow safely calling nukefile from a run queue handler Originally dorunq assumed that the queue entry remained first in the queue after the script eval, and blindly removed it. However, if the handler calls nukefile, it may not be the case anymore, and a random queue entry gets dropped instead. This makes dorunq remove the entry before calling the script, and adds a global variable to allow other functions to determine if they are called from within a dorunq handler. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-09 12:41:50 +02:00
if {$runq eq {} && ![info exists currunq]} {
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
after idle dorunq
}
lappend runq [list $fd $script]
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc nukefile {fd} {
global runq
for {set i 0} {$i < [llength $runq]} {} {
if {[lindex $runq $i 0] eq $fd} {
set runq [lreplace $runq $i $i]
} else {
incr i
}
}
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
proc dorunq {} {
gitk: Allow safely calling nukefile from a run queue handler Originally dorunq assumed that the queue entry remained first in the queue after the script eval, and blindly removed it. However, if the handler calls nukefile, it may not be the case anymore, and a random queue entry gets dropped instead. This makes dorunq remove the entry before calling the script, and adds a global variable to allow other functions to determine if they are called from within a dorunq handler. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-09 12:41:50 +02:00
global isonrunq runq currunq
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set tstart [clock clicks -milliseconds]
set t0 $tstart
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
while {[llength $runq] > 0} {
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set fd [lindex $runq 0 0]
set script [lindex $runq 0 1]
gitk: Allow safely calling nukefile from a run queue handler Originally dorunq assumed that the queue entry remained first in the queue after the script eval, and blindly removed it. However, if the handler calls nukefile, it may not be the case anymore, and a random queue entry gets dropped instead. This makes dorunq remove the entry before calling the script, and adds a global variable to allow other functions to determine if they are called from within a dorunq handler. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-09 12:41:50 +02:00
set currunq [lindex $runq 0]
set runq [lrange $runq 1 end]
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set repeat [eval $script]
gitk: Allow safely calling nukefile from a run queue handler Originally dorunq assumed that the queue entry remained first in the queue after the script eval, and blindly removed it. However, if the handler calls nukefile, it may not be the case anymore, and a random queue entry gets dropped instead. This makes dorunq remove the entry before calling the script, and adds a global variable to allow other functions to determine if they are called from within a dorunq handler. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-09 12:41:50 +02:00
unset currunq
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set t1 [clock clicks -milliseconds]
set t [expr {$t1 - $t0}]
if {$repeat ne {} && $repeat} {
if {$fd eq {} || $repeat == 2} {
# script returns 1 if it wants to be readded
# file readers return 2 if they could do more straight away
lappend runq [list $fd $script]
} else {
fileevent $fd readable [list filereadable $fd $script]
}
} elseif {$fd eq {}} {
unset isonrunq($script)
}
set t0 $t1
if {$t1 - $tstart >= 80} break
}
if {$runq ne {}} {
after idle dorunq
}
}
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
proc reg_instance {fd} {
global commfd leftover loginstance
set i [incr loginstance]
set commfd($i) $fd
set leftover($i) {}
return $i
}
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
proc unmerged_files {files} {
global nr_unmerged
# find the list of unmerged files
set mlist {}
set nr_unmerged 0
if {[catch {
set fd [open "| git ls-files -u" r]
} err]} {
show_error {} . "[mc "Couldn't get list of unmerged files:"] $err"
exit 1
}
while {[gets $fd line] >= 0} {
set i [string first "\t" $line]
if {$i < 0} continue
set fname [string range $line [expr {$i+1}] end]
if {[lsearch -exact $mlist $fname] >= 0} continue
incr nr_unmerged
if {$files eq {} || [path_filter $files $fname]} {
lappend mlist $fname
}
}
catch {close $fd}
return $mlist
}
proc parseviewargs {n arglist} {
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
set vdatemode($n) 0
set vmergeonly($n) 0
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
set glflags {}
set diffargs {}
set nextisval 0
set revargs {}
set origargs $arglist
set allknown 1
set filtered 0
set i -1
foreach arg $arglist {
incr i
if {$nextisval} {
lappend glflags $arg
set nextisval 0
continue
}
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
switch -glob -- $arg {
"-d" -
"--date-order" {
set vdatemode($n) 1
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
# remove from origargs in case we hit an unknown option
set origargs [lreplace $origargs $i $i]
incr i -1
}
"-[puabwcrRBMC]" -
"--no-renames" - "--full-index" - "--binary" - "--abbrev=*" -
"--find-copies-harder" - "-l*" - "--ext-diff" - "--no-ext-diff" -
"--src-prefix=*" - "--dst-prefix=*" - "--no-prefix" -
"-O*" - "--text" - "--full-diff" - "--ignore-space-at-eol" -
"--ignore-space-change" - "-U*" - "--unified=*" {
gitk: Fix switch statement in parseviewargs In Tcl, a comment in a switch command where a pattern would be expected doesn't do what one would expect, so this moves the comments inside the actions. Doing that shows up an extra "-" which this also removes. With this, --merge is now handled properly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:44:20 +01:00
# These request or affect diff output, which we don't want.
# Some could be used to set our defaults for diff display.
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
lappend diffargs $arg
}
"--raw" - "--patch-with-raw" - "--patch-with-stat" -
"--name-only" - "--name-status" - "--color" - "--color-words" -
"--log-size" - "--pretty=*" - "--decorate" - "--abbrev-commit" -
"--cc" - "-z" - "--header" - "--parents" - "--boundary" -
"--no-color" - "-g" - "--walk-reflogs" - "--no-walk" -
"--timestamp" - "relative-date" - "--date=*" - "--stdin" -
"--objects" - "--objects-edge" - "--reverse" {
gitk: Fix switch statement in parseviewargs In Tcl, a comment in a switch command where a pattern would be expected doesn't do what one would expect, so this moves the comments inside the actions. Doing that shows up an extra "-" which this also removes. With this, --merge is now handled properly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:44:20 +01:00
# These cause our parsing of git log's output to fail, or else
# they're options we want to set ourselves, so ignore them.
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
}
"--stat=*" - "--numstat" - "--shortstat" - "--summary" -
"--check" - "--exit-code" - "--quiet" - "--topo-order" -
"--full-history" - "--dense" - "--sparse" -
"--follow" - "--left-right" - "--encoding=*" {
gitk: Fix switch statement in parseviewargs In Tcl, a comment in a switch command where a pattern would be expected doesn't do what one would expect, so this moves the comments inside the actions. Doing that shows up an extra "-" which this also removes. With this, --merge is now handled properly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:44:20 +01:00
# These are harmless, and some are even useful
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
lappend glflags $arg
}
"--diff-filter=*" - "--no-merges" - "--unpacked" -
"--max-count=*" - "--skip=*" - "--since=*" - "--after=*" -
"--until=*" - "--before=*" - "--max-age=*" - "--min-age=*" -
"--author=*" - "--committer=*" - "--grep=*" - "-[iE]" -
"--remove-empty" - "--first-parent" - "--cherry-pick" -
gitk: Add option 'Simple history' to the options menu When clicked, the option --simplify-by-decoration is added to gitk/git log. This yields to a simplified history where only decorated commits are shown, i.e. those with a yellow tag or a green branch flag. Signed-off-by: Dirk Suesserott <newsletter@dirk.my1.cc> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-05-21 15:35:40 +02:00
"-S*" - "--pickaxe-all" - "--pickaxe-regex" -
"--simplify-by-decoration" {
gitk: Fix switch statement in parseviewargs In Tcl, a comment in a switch command where a pattern would be expected doesn't do what one would expect, so this moves the comments inside the actions. Doing that shows up an extra "-" which this also removes. With this, --merge is now handled properly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:44:20 +01:00
# These mean that we get a subset of the commits
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
set filtered 1
lappend glflags $arg
}
"-n" {
gitk: Fix switch statement in parseviewargs In Tcl, a comment in a switch command where a pattern would be expected doesn't do what one would expect, so this moves the comments inside the actions. Doing that shows up an extra "-" which this also removes. With this, --merge is now handled properly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:44:20 +01:00
# This appears to be the only one that has a value as a
# separate word following it
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
set filtered 1
set nextisval 1
lappend glflags $arg
}
gitk: Fix bug in accessing undefined "notflag" variable As pointed out by Johannes Sixt and Alexander Gavrilov, commit 2958228430b63f2e38c55519d1f98d8d6d9e23f3 ("gitk: Fix switch statement in parseviewargs") exposed a latent bug in that $notflag was never initialized. Since it isn't used either, this removes it entirely. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-01 23:17:46 +01:00
"--not" - "--all" {
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
lappend revargs $arg
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
}
"--merge" {
set vmergeonly($n) 1
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
# git rev-parse doesn't understand --merge
lappend revargs --gitk-symmetric-diff-marker MERGE_HEAD...HEAD
}
"-*" {
gitk: Fix switch statement in parseviewargs In Tcl, a comment in a switch command where a pattern would be expected doesn't do what one would expect, so this moves the comments inside the actions. Doing that shows up an extra "-" which this also removes. With this, --merge is now handled properly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:44:20 +01:00
# Other flag arguments including -<n>
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
if {[string is digit -strict [string range $arg 1 end]]} {
set filtered 1
} else {
# a flag argument that we don't recognize;
# that means we can't optimize
set allknown 0
}
lappend glflags $arg
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
}
default {
gitk: Fix switch statement in parseviewargs In Tcl, a comment in a switch command where a pattern would be expected doesn't do what one would expect, so this moves the comments inside the actions. Doing that shows up an extra "-" which this also removes. With this, --merge is now handled properly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:44:20 +01:00
# Non-flag arguments specify commits or ranges of commits
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
if {[string match "*...*" $arg]} {
lappend revargs --gitk-symmetric-diff-marker
}
lappend revargs $arg
}
}
}
set vdflags($n) $diffargs
set vflags($n) $glflags
set vrevs($n) $revargs
set vfiltered($n) $filtered
set vorigargs($n) $origargs
return $allknown
}
proc parseviewrevs {view revs} {
global vposids vnegids
if {$revs eq {}} {
set revs HEAD
}
if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
# we get stdout followed by stderr in $err
# for an unknown rev, git rev-parse echoes it and then errors out
set errlines [split $err "\n"]
set badrev {}
for {set l 0} {$l < [llength $errlines]} {incr l} {
set line [lindex $errlines $l]
if {!([string length $line] == 40 && [string is xdigit $line])} {
if {[string match "fatal:*" $line]} {
if {[string match "fatal: ambiguous argument*" $line]
&& $badrev ne {}} {
if {[llength $badrev] == 1} {
set err "unknown revision $badrev"
} else {
set err "unknown revisions: [join $badrev ", "]"
}
} else {
set err [join [lrange $errlines $l end] "\n"]
}
break
}
lappend badrev $line
}
}
gitk: Add untranslated error messages to translation Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-12 11:39:43 +02:00
error_popup "[mc "Error parsing revisions:"] $err"
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
return {}
}
set ret {}
set pos {}
set neg {}
set sdm 0
foreach id [split $ids "\n"] {
if {$id eq "--gitk-symmetric-diff-marker"} {
set sdm 4
} elseif {[string match "^*" $id]} {
if {$sdm != 1} {
lappend ret $id
if {$sdm == 3} {
set sdm 0
}
}
lappend neg [string range $id 1 end]
} else {
if {$sdm != 2} {
lappend ret $id
} else {
gitk: Fix direction of symmetric difference in optimized mode ee66e08 (gitk: Make updates go faster, 2008-05-09) implemented an optimized mode where gitk parses the arguments with rev-parse, and manually reads history in chunks. As mentioned in the commit message, symmetric differences are a problem there: One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). However, git-rev-parse returns a...b in the swapped order b a ^merge_base(a,b) This has been the case since at least 1f8115b (the state of master at the time of the abovementioned ee66e08; Merge branch 'maint', 2008-05-08). So gitk flipped the sides of symmetric differences whenever it was in optimized mode. Fix this by swapping the sides of the reconstruction code. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-05 23:15:36 +02:00
lset ret end $id...[lindex $ret end]
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
}
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
lappend pos $id
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
}
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
incr sdm -1
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
}
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
set vposids($view) $pos
set vnegids($view) $neg
return $ret
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
}
gitk: Correct a few strings and comments to say "git log" ... instead of "git rev-list", since we now use git log for generating the list of commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:14:17 +01:00
# Start off a git log process and arrange to read its output
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
proc start_rev_list {view} {
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
global startmsecs commitidx viewcomplete curview
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
global tclencoding
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
global viewargs viewargscmd viewfiles vfilelimit
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
global showlocalchanges
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
global viewactive viewinstances vmergeonly
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
global mainheadid viewmainheadid viewmainheadid_orig
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
global vcanopt vflags vrevs vorigargs
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
set startmsecs [clock clicks -milliseconds]
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
set commitidx($view) 0
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
# these are set this way for the error exits
set viewcomplete($view) 1
set viewactive($view) 0
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
varcinit $view
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
set args $viewargs($view)
if {$viewargscmd($view) ne {}} {
if {[catch {
set str [exec sh -c $viewargscmd($view)]
} err]} {
gitk: Add untranslated error messages to translation Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-12 11:39:43 +02:00
error_popup "[mc "Error executing --argscmd command:"] $err"
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
return 0
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
}
set args [concat $args [split $str "\n"]]
}
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
set vcanopt($view) [parseviewargs $view $args]
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
set files $viewfiles($view)
if {$vmergeonly($view)} {
set files [unmerged_files $files]
if {$files eq {}} {
global nr_unmerged
if {$nr_unmerged == 0} {
error_popup [mc "No files selected: --merge specified but\
no files are unmerged."]
} else {
error_popup [mc "No files selected: --merge specified but\
no unmerged files are within file limit."]
}
return 0
}
}
set vfilelimit($view) $files
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
if {$vcanopt($view)} {
set revs [parseviewrevs $view $vrevs($view)]
if {$revs eq {}} {
return 0
}
set args [concat $vflags($view) $revs]
} else {
set args $vorigargs($view)
}
gitk: Add braces around if expressions Apparently this simplifies things for the parser/compiler and makes it go slightly faster (since without the braces, it potentially has to do two levels of substitutions rather than one). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:10:18 +01:00
if {[catch {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set fd [open [concat | git log --no-color -z --pretty=raw --parents \
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
--boundary $args "--" $files] r]
gitk: Add braces around if expressions Apparently this simplifies things for the parser/compiler and makes it go slightly faster (since without the braces, it potentially has to do two levels of substitutions rather than one). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:10:18 +01:00
} err]} {
Merge branch 'master' into dev
2007-12-20 00:25:50 +01:00
error_popup "[mc "Error executing git log:"] $err"
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
return 0
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
}
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
set i [reg_instance $fd]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set viewinstances($view) [list $i]
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
set viewmainheadid($view) $mainheadid
set viewmainheadid_orig($view) $mainheadid
if {$files ne {} && $mainheadid ne {}} {
get_viewmainhead $view
}
if {$showlocalchanges && $viewmainheadid($view) ne {}} {
interestedin $viewmainheadid($view) dodiffindex
gitk: Get rid of lookingforhead, use commitinterest instead Now that we have a general-purpose way of taking some action when a commit ID of interest is encountered, use that for triggering the git diff-index process when we find the currently checked-out head, rather than the special-purpose lookingforhead variable. Also do the commitinterest processing in getcommitlines rather than in showstuff. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-15 01:33:39 +02:00
}
[PATCH] gitk: Ignore ctrl-z as EOF on windows Cygwin's Tcl is configured to honor any occurence of ctrl-z as an end-of-file marker, while some commits in the git repository and possibly elsewhere include that character in the commit comment. This causes gitk ignore commit history following such a comment and incorrect graphs. This change affects only Windows as Tcl on other platforms already has eofchar == {}. This fixes problems noted by me and by Ray Lehtiniemi, and the fix was suggested by Shawn Pierce. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-18 00:42:04 +02:00
fconfigure $fd -blocking 0 -translation lf -eofchar {}
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
if {$tclencoding != {}} {
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
fconfigure $fd -encoding $tclencoding
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
}
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
filerun $fd [list getcommitlines $fd $i $view 0]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
nowbusy $view [mc "Reading"]
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
set viewcomplete($view) 0
set viewactive($view) 1
return 1
gitk: Factored out some common code into a new start_rev_list procedure Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-01 12:42:46 +01:00
}
gitk: Kill back-end processes on window close When collecting commits for a rarely changed, or recently created file or directory, rev-list may work for a noticeable period of time without producing any output. Such processes don't receive SIGPIPE for a while after gitk is closed, thus becoming runaway CPU hogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-12 14:09:28 +02:00
proc stop_instance {inst} {
global commfd leftover
set fd $commfd($inst)
catch {
set pid [pid $fd]
gitk: On Windows, use a Cygwin-specific flag for kill MSysGit compiles git binaries as native Windows executables, so they cannot be killed unless a special flag is specified. This flag is implemented by the Cygwin version of kill, which is also included in MSysGit. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-14 22:35:42 +02:00
if {$::tcl_platform(platform) eq {windows}} {
exec kill -f $pid
} else {
exec kill $pid
}
gitk: Kill back-end processes on window close When collecting commits for a rarely changed, or recently created file or directory, rev-list may work for a noticeable period of time without producing any output. Such processes don't receive SIGPIPE for a while after gitk is closed, thus becoming runaway CPU hogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-12 14:09:28 +02:00
}
catch {close $fd}
nukefile $fd
unset commfd($inst)
unset leftover($inst)
}
proc stop_backends {} {
global commfd
foreach inst [array names commfd] {
stop_instance $inst
}
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc stop_rev_list {view} {
gitk: Kill back-end processes on window close When collecting commits for a rarely changed, or recently created file or directory, rev-list may work for a noticeable period of time without producing any output. Such processes don't receive SIGPIPE for a while after gitk is closed, thus becoming runaway CPU hogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-12 14:09:28 +02:00
global viewinstances
gitk: Don't reread git-rev-list output from scratch on view switch Previously, if we switched away from a view before we had finished reading the git-rev-list output for it and laying out the graph, we would discard the partially-laid-out graph and reread it from scratch if we switched back to the view. With this, we preserve the state of the partially-laid-out graph in viewdata($view) and restore it if we switch back. The pipe to git-rev-list remains open but we just don't read from it any more until we switch back to that view. This also makes linesegends a list rather than an array, which turns out to be slightly faster, as well as being easier to save and restore. The `update' menu item now kills the git-rev-list process if there is one still running when we do the update. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-17 01:56:02 +02:00
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
foreach inst $viewinstances($view) {
gitk: Kill back-end processes on window close When collecting commits for a rarely changed, or recently created file or directory, rev-list may work for a noticeable period of time without producing any output. Such processes don't receive SIGPIPE for a while after gitk is closed, thus becoming runaway CPU hogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-12 14:09:28 +02:00
stop_instance $inst
gitk: Don't reread git-rev-list output from scratch on view switch Previously, if we switched away from a view before we had finished reading the git-rev-list output for it and laying out the graph, we would discard the partially-laid-out graph and reread it from scratch if we switched back to the view. With this, we preserve the state of the partially-laid-out graph in viewdata($view) and restore it if we switch back. The pipe to git-rev-list remains open but we just don't read from it any more until we switch back to that view. This also makes linesegends a list rather than an array, which turns out to be slightly faster, as well as being easier to save and restore. The `update' menu item now kills the git-rev-list process if there is one still running when we do the update. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-17 01:56:02 +02:00
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set viewinstances($view) {}
gitk: Don't reread git-rev-list output from scratch on view switch Previously, if we switched away from a view before we had finished reading the git-rev-list output for it and laying out the graph, we would discard the partially-laid-out graph and reread it from scratch if we switched back to the view. With this, we preserve the state of the partially-laid-out graph in viewdata($view) and restore it if we switch back. The pipe to git-rev-list remains open but we just don't read from it any more until we switch back to that view. This also makes linesegends a list rather than an array, which turns out to be slightly faster, as well as being easier to save and restore. The `update' menu item now kills the git-rev-list process if there is one still running when we do the update. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-17 01:56:02 +02:00
}
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
proc reset_pending_select {selid} {
gitk: Add option to specify the default commit on command line Other GUI tools may need to start gitk and make it automatically select a certain commit. This adds a new command-line option --select-commit=id to make that possible. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:27:44 +02:00
global pending_select mainheadid selectheadid
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
if {$selid ne {}} {
set pending_select $selid
gitk: Add option to specify the default commit on command line Other GUI tools may need to start gitk and make it automatically select a certain commit. This adds a new command-line option --select-commit=id to make that possible. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:27:44 +02:00
} elseif {$selectheadid ne {}} {
set pending_select $selectheadid
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
} else {
set pending_select $mainheadid
}
}
proc getcommits {selid} {
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
global canv curview need_redisplay viewactive
gitk: Factored out some common code into a new start_rev_list procedure Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-01 12:42:46 +01:00
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
initlayout
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
if {[start_rev_list $curview]} {
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
reset_pending_select $selid
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
show_status [mc "Reading commits..."]
set need_redisplay 1
} else {
show_status [mc "No commits selected"]
}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc updatecommits {} {
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
global curview vcanopt vorigargs vfilelimit viewinstances
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
global viewactive viewcomplete tclencoding
global startmsecs showneartags showlocalchanges
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
global mainheadid viewmainheadid viewmainheadid_orig pending_select
Merge branch 'master' into dev
2008-03-11 12:21:39 +01:00
global isworktree
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
global varcid vposids vnegids vflags vrevs
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
Merge branch 'master' into dev
2008-03-11 12:21:39 +01:00
set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
rereadrefs
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
set view $curview
if {$mainheadid ne $viewmainheadid_orig($view)} {
if {$showlocalchanges} {
gitk: Don't try to show local changes from a head that isn't shown When updating the display, if the checked-out head has moved on and isn't currently shown, and there are local changes, we could try to insert a fake row with a parent that isn't displayed, leading to a Tcl error. This is because we check whether the checked-out head is displayed before rereading the references (which is when we discover that the head has moved). This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-29 11:13:34 +01:00
dohidelocalchanges
}
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
set viewmainheadid($view) $mainheadid
set viewmainheadid_orig($view) $mainheadid
if {$vfilelimit($view) ne {}} {
get_viewmainhead $view
gitk: Don't try to show local changes from a head that isn't shown When updating the display, if the checked-out head has moved on and isn't currently shown, and there are local changes, we could try to insert a fake row with a parent that isn't displayed, leading to a Tcl error. This is because we check whether the checked-out head is displayed before rereading the references (which is when we discover that the head has moved). This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-29 11:13:34 +01:00
}
}
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
if {$showlocalchanges} {
doshowlocalchanges
}
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
if {$vcanopt($view)} {
set oldpos $vposids($view)
set oldneg $vnegids($view)
set revs [parseviewrevs $view $vrevs($view)]
if {$revs eq {}} {
return
}
# note: getting the delta when negative refs change is hard,
# and could require multiple git log invocations, so in that
# case we ask git log for all the commits (not just the delta)
if {$oldneg eq $vnegids($view)} {
set newrevs {}
set npos 0
# take out positive refs that we asked for before or
# that we have already seen
foreach rev $revs {
if {[string length $rev] == 40} {
if {[lsearch -exact $oldpos $rev] < 0
&& ![info exists varcid($view,$rev)]} {
lappend newrevs $rev
incr npos
}
} else {
lappend $newrevs $rev
}
}
if {$npos == 0} return
set revs $newrevs
set vposids($view) [lsort -unique [concat $oldpos $vposids($view)]]
}
set args [concat $vflags($view) $revs --not $oldpos]
} else {
set args $vorigargs($view)
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[catch {
set fd [open [concat | git log --no-color -z --pretty=raw --parents \
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
--boundary $args "--" $vfilelimit($view)] r]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
} err]} {
gitk: Add untranslated error messages to translation Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-12 11:39:43 +02:00
error_popup "[mc "Error executing git log:"] $err"
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
return
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
if {$viewactive($view) == 0} {
set startmsecs [clock clicks -milliseconds]
}
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
set i [reg_instance $fd]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
lappend viewinstances($view) $i
fconfigure $fd -blocking 0 -translation lf -eofchar {}
if {$tclencoding != {}} {
fconfigure $fd -encoding $tclencoding
}
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
filerun $fd [list getcommitlines $fd $i $view 1]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
incr viewactive($view)
set viewcomplete($view) 0
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
reset_pending_select {}
gitk: Mark some more strings for translation Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-30 21:17:25 +02:00
nowbusy $view [mc "Reading"]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$showneartags} {
getallcommits
}
}
proc reloadcommits {} {
global curview viewcomplete selectedline currentid thickerline
global showneartags treediffs commitinterest cached_commitrow
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
global targetid
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
set selid {}
if {$selectedline ne {}} {
set selid $currentid
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {!$viewcomplete($curview)} {
stop_rev_list $curview
}
resetvarcs $curview
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
set selectedline {}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
catch {unset currentid}
catch {unset thickerline}
catch {unset treediffs}
readrefs
changedrefs
if {$showneartags} {
getallcommits
}
clear_display
catch {unset commitinterest}
catch {unset cached_commitrow}
gitk: Fix some corner cases in the targetid/targetrow stuff * Make sure targetrow is never >= numcommits * Don't try to do anything about the target row if the targetid is no longer in the view; it'll just cause Tcl errors * In insertrow, increment targetrow if we are inserting the fake commit at or before the target row * In removerow, if we are removing the target row, make it the next one instead. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-01 23:59:39 +01:00
catch {unset targetid}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
setcanvscroll
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
getcommits $selid
gitk: Fix bug where editing an existing view would cause an infinite loop This fixes a bug where changing the commit range or file list for an existing view and then clicking OK would cause gitk to go into an infinite loop. The problem was that newviewok was invoking reloadcommits via "run reloadcommits", but reloadcommits wasn't explicitly returning 0, and whatever it was returning was causing dorunq to run it over and over again. This fixes it by making reloadcommits return 0. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-15 12:30:40 +01:00
return 0
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
# This makes a string representation of a positive integer which
# sorts as a string in numerical order
proc strrep {n} {
if {$n < 16} {
return [format "%x" $n]
} elseif {$n < 256} {
return [format "x%.2x" $n]
} elseif {$n < 65536} {
return [format "y%.4x" $n]
}
return [format "z%.8x" $n]
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
# Procedures used in reordering commits from git log (without
# --topo-order) into the order for display.
proc varcinit {view} {
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
global varcstart vupptr vdownptr vleftptr vbackptr varctok varcrow
global vtokmod varcmod vrowmod varcix vlastins
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set varcstart($view) {{}}
set vupptr($view) {0}
set vdownptr($view) {0}
set vleftptr($view) {0}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set vbackptr($view) {0}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set varctok($view) {{}}
set varcrow($view) {{}}
set vtokmod($view) {}
set varcmod($view) 0
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
set vrowmod($view) 0
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set varcix($view) {{}}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set vlastins($view) {0}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
proc resetvarcs {view} {
global varcid varccommits parents children vseedcount ordertok
foreach vid [array names varcid $view,*] {
unset varcid($vid)
unset children($vid)
unset parents($vid)
}
# some commits might have children but haven't been seen yet
foreach vid [array names children $view,*] {
unset children($vid)
}
foreach va [array names varccommits $view,*] {
unset varccommits($va)
}
foreach vd [array names vseedcount $view,*] {
unset vseedcount($vd)
}
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
catch {unset ordertok}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Don't filter view arguments through git rev-parse Previously we passed the arguments indicating what commits the user wants to view through git rev-parse to get a list of IDs (positive and negative), then gave that to git log. This had a couple of problems, notably that --merge and --left-right didn't get handled properly. Instead we now just pass the original arguments to git log. When doing an update, we append --not followed by the list of commits we have seen that have no children, since we have got (or will get) their ancestors from the first git log. If the first git log isn't finished yet, we might get some duplicates from the second git log, but that doesn't cause any problem. Also get rid of the unused vnextroot variable. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:19:35 +01:00
# returns a list of the commits with no children
proc seeds {v} {
global vdownptr vleftptr varcstart
set ret {}
set a [lindex $vdownptr($v) 0]
while {$a != 0} {
lappend ret [lindex $varcstart($v) $a]
set a [lindex $vleftptr($v) $a]
}
return $ret
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc newvarc {view id} {
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
global varcid varctok parents children vdatemode
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
global vupptr vdownptr vleftptr vbackptr varcrow varcix varcstart
global commitdata commitinfo vseedcount varccommits vlastins
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set a [llength $varctok($view)]
set vid $view,$id
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
if {[llength $children($vid)] == 0 || $vdatemode($view)} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![info exists commitinfo($id)]} {
parsecommit $id $commitdata($id) 1
}
set cdate [lindex $commitinfo($id) 4]
if {![string is integer -strict $cdate]} {
set cdate 0
}
if {![info exists vseedcount($view,$cdate)]} {
set vseedcount($view,$cdate) -1
}
set c [incr vseedcount($view,$cdate)]
set cdate [expr {$cdate ^ 0xffffffff}]
set tok "s[strrep $cdate][strrep $c]"
} else {
set tok {}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
}
set ka 0
if {[llength $children($vid)] > 0} {
set kid [lindex $children($vid) end]
set k $varcid($view,$kid)
if {[string compare [lindex $varctok($view) $k] $tok] > 0} {
set ki $kid
set ka $k
set tok [lindex $varctok($view) $k]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
}
if {$ka != 0} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set i [lsearch -exact $parents($view,$ki) $id]
set j [expr {[llength $parents($view,$ki)] - 1 - $i}]
append tok [strrep $j]
}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set c [lindex $vlastins($view) $ka]
if {$c == 0 || [string compare $tok [lindex $varctok($view) $c]] < 0} {
set c $ka
set b [lindex $vdownptr($view) $ka]
} else {
set b [lindex $vleftptr($view) $c]
}
while {$b != 0 && [string compare $tok [lindex $varctok($view) $b]] >= 0} {
set c $b
set b [lindex $vleftptr($view) $c]
}
if {$c == $ka} {
lset vdownptr($view) $ka $a
lappend vbackptr($view) 0
} else {
lset vleftptr($view) $c $a
lappend vbackptr($view) $c
}
lset vlastins($view) $ka $a
lappend vupptr($view) $ka
lappend vleftptr($view) $b
if {$b != 0} {
lset vbackptr($view) $b $a
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
lappend varctok($view) $tok
lappend varcstart($view) $id
lappend vdownptr($view) 0
lappend varcrow($view) {}
lappend varcix($view) {}
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
set varccommits($view,$a) {}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
lappend vlastins($view) 0
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
return $a
}
proc splitvarc {p v} {
gitk: Fix possible infinite loop and display corruption This fixes an issue reported by Johannes Sixt on the git mailing list: > This recipe sends gitk into an endless loop. In git.git do: > > cd t > # remove chmod a+x A near the end of the file > sed -i 's/chmod/: chmod/' t3400-rebase.sh > sh t3400-rebase.sh --debug > cd trash\ directory.t3400-rebase/ > gitk master modechange modechange@{1} > > > I briefly see the history chart, but the dot that should be modechange@{1} > is missing. One automatically selected commit is shown in the diff section > below. But then the commit list is cleared and gitk goes into an infinite > loop. > > Things work alright if either modechange@{1} is dropped, or the 'chmod' > line is left unchanged, which is a bit strange. > > This is with git version 1.6.1.2.390.gba743 There were actually two problems. This recipe created a situation where git log would output a child commit after its parent. This meant that we called fix_reversal which called splitvarc, which should call modify_arc to note the fact that it has modified the arc that it has just split. It wasn't, which meant that displayorder and other variables got into an inconsistent state (a commit appearing twice in displayorder). This then meant that the targetrow/targetid logic in drawvisible thought it need to redraw each time. That, together with the fact that drawvisible called drawcommits which called drawvisible if a redraw was needed, led to the infinite loop. In fact drawvisible is now the only caller of drawcommits. Thus, the start and end row arguments to drawcommits always encompass the whole visible area, so drawcommits doesn't need to call drawvisible to redraw; it just needs to clear the screen and draw what it's been asked to. This fixes these two problems by adding a call to modify_arc in splitvarc and by taking out the call to drawvisible in drawcommits. It also removes an unrelated left-over debugging puts in external_blame. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-01 23:38:17 +01:00
global varcid varcstart varccommits varctok vtokmod
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
global vupptr vdownptr vleftptr vbackptr varcix varcrow vlastins
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set oa $varcid($v,$p)
gitk: Fix possible infinite loop and display corruption This fixes an issue reported by Johannes Sixt on the git mailing list: > This recipe sends gitk into an endless loop. In git.git do: > > cd t > # remove chmod a+x A near the end of the file > sed -i 's/chmod/: chmod/' t3400-rebase.sh > sh t3400-rebase.sh --debug > cd trash\ directory.t3400-rebase/ > gitk master modechange modechange@{1} > > > I briefly see the history chart, but the dot that should be modechange@{1} > is missing. One automatically selected commit is shown in the diff section > below. But then the commit list is cleared and gitk goes into an infinite > loop. > > Things work alright if either modechange@{1} is dropped, or the 'chmod' > line is left unchanged, which is a bit strange. > > This is with git version 1.6.1.2.390.gba743 There were actually two problems. This recipe created a situation where git log would output a child commit after its parent. This meant that we called fix_reversal which called splitvarc, which should call modify_arc to note the fact that it has modified the arc that it has just split. It wasn't, which meant that displayorder and other variables got into an inconsistent state (a commit appearing twice in displayorder). This then meant that the targetrow/targetid logic in drawvisible thought it need to redraw each time. That, together with the fact that drawvisible called drawcommits which called drawvisible if a redraw was needed, led to the infinite loop. In fact drawvisible is now the only caller of drawcommits. Thus, the start and end row arguments to drawcommits always encompass the whole visible area, so drawcommits doesn't need to call drawvisible to redraw; it just needs to clear the screen and draw what it's been asked to. This fixes these two problems by adding a call to modify_arc in splitvarc and by taking out the call to drawvisible in drawcommits. It also removes an unrelated left-over debugging puts in external_blame. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-01 23:38:17 +01:00
set otok [lindex $varctok($v) $oa]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set ac $varccommits($v,$oa)
set i [lsearch -exact $varccommits($v,$oa) $p]
if {$i <= 0} return
set na [llength $varctok($v)]
# "%" sorts before "0"...
gitk: Fix possible infinite loop and display corruption This fixes an issue reported by Johannes Sixt on the git mailing list: > This recipe sends gitk into an endless loop. In git.git do: > > cd t > # remove chmod a+x A near the end of the file > sed -i 's/chmod/: chmod/' t3400-rebase.sh > sh t3400-rebase.sh --debug > cd trash\ directory.t3400-rebase/ > gitk master modechange modechange@{1} > > > I briefly see the history chart, but the dot that should be modechange@{1} > is missing. One automatically selected commit is shown in the diff section > below. But then the commit list is cleared and gitk goes into an infinite > loop. > > Things work alright if either modechange@{1} is dropped, or the 'chmod' > line is left unchanged, which is a bit strange. > > This is with git version 1.6.1.2.390.gba743 There were actually two problems. This recipe created a situation where git log would output a child commit after its parent. This meant that we called fix_reversal which called splitvarc, which should call modify_arc to note the fact that it has modified the arc that it has just split. It wasn't, which meant that displayorder and other variables got into an inconsistent state (a commit appearing twice in displayorder). This then meant that the targetrow/targetid logic in drawvisible thought it need to redraw each time. That, together with the fact that drawvisible called drawcommits which called drawvisible if a redraw was needed, led to the infinite loop. In fact drawvisible is now the only caller of drawcommits. Thus, the start and end row arguments to drawcommits always encompass the whole visible area, so drawcommits doesn't need to call drawvisible to redraw; it just needs to clear the screen and draw what it's been asked to. This fixes these two problems by adding a call to modify_arc in splitvarc and by taking out the call to drawvisible in drawcommits. It also removes an unrelated left-over debugging puts in external_blame. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-01 23:38:17 +01:00
set tok "$otok%[strrep $i]"
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
lappend varctok($v) $tok
lappend varcrow($v) {}
lappend varcix($v) {}
set varccommits($v,$oa) [lrange $ac 0 [expr {$i - 1}]]
set varccommits($v,$na) [lrange $ac $i end]
lappend varcstart($v) $p
foreach id $varccommits($v,$na) {
set varcid($v,$id) $na
}
lappend vdownptr($v) [lindex $vdownptr($v) $oa]
gitk: Fix bug where arcs could get lost Because we weren't fixing up vlastins when moving an arc from one place to another, it was possible for us later to decide to move an arc to the wrong place, and end up with an arc disconnected from the rest of the graph. This fixes it by updating vlastins when necessary. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-18 00:44:33 +01:00
lappend vlastins($v) [lindex $vlastins($v) $oa]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
lset vdownptr($v) $oa $na
gitk: Fix bug where arcs could get lost Because we weren't fixing up vlastins when moving an arc from one place to another, it was possible for us later to decide to move an arc to the wrong place, and end up with an arc disconnected from the rest of the graph. This fixes it by updating vlastins when necessary. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-18 00:44:33 +01:00
lset vlastins($v) $oa 0
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
lappend vupptr($v) $oa
lappend vleftptr($v) 0
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
lappend vbackptr($v) 0
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
for {set b [lindex $vdownptr($v) $na]} {$b != 0} {set b [lindex $vleftptr($v) $b]} {
lset vupptr($v) $b $na
}
gitk: Fix possible infinite loop and display corruption This fixes an issue reported by Johannes Sixt on the git mailing list: > This recipe sends gitk into an endless loop. In git.git do: > > cd t > # remove chmod a+x A near the end of the file > sed -i 's/chmod/: chmod/' t3400-rebase.sh > sh t3400-rebase.sh --debug > cd trash\ directory.t3400-rebase/ > gitk master modechange modechange@{1} > > > I briefly see the history chart, but the dot that should be modechange@{1} > is missing. One automatically selected commit is shown in the diff section > below. But then the commit list is cleared and gitk goes into an infinite > loop. > > Things work alright if either modechange@{1} is dropped, or the 'chmod' > line is left unchanged, which is a bit strange. > > This is with git version 1.6.1.2.390.gba743 There were actually two problems. This recipe created a situation where git log would output a child commit after its parent. This meant that we called fix_reversal which called splitvarc, which should call modify_arc to note the fact that it has modified the arc that it has just split. It wasn't, which meant that displayorder and other variables got into an inconsistent state (a commit appearing twice in displayorder). This then meant that the targetrow/targetid logic in drawvisible thought it need to redraw each time. That, together with the fact that drawvisible called drawcommits which called drawvisible if a redraw was needed, led to the infinite loop. In fact drawvisible is now the only caller of drawcommits. Thus, the start and end row arguments to drawcommits always encompass the whole visible area, so drawcommits doesn't need to call drawvisible to redraw; it just needs to clear the screen and draw what it's been asked to. This fixes these two problems by adding a call to modify_arc in splitvarc and by taking out the call to drawvisible in drawcommits. It also removes an unrelated left-over debugging puts in external_blame. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-01 23:38:17 +01:00
if {[string compare $otok $vtokmod($v)] <= 0} {
modify_arc $v $oa
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
proc renumbervarc {a v} {
global parents children varctok varcstart varccommits
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
global vupptr vdownptr vleftptr vbackptr vlastins varcid vtokmod vdatemode
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set t1 [clock clicks -milliseconds]
set todo {}
set isrelated($a) 1
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set kidchanged($a) 1
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set ntot 0
while {$a != 0} {
if {[info exists isrelated($a)]} {
lappend todo $a
set id [lindex $varccommits($v,$a) end]
foreach p $parents($v,$id) {
if {[info exists varcid($v,$p)]} {
set isrelated($varcid($v,$p)) 1
}
}
}
incr ntot
set b [lindex $vdownptr($v) $a]
if {$b == 0} {
while {$a != 0} {
set b [lindex $vleftptr($v) $a]
if {$b != 0} break
set a [lindex $vupptr($v) $a]
}
}
set a $b
}
foreach a $todo {
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
if {![info exists kidchanged($a)]} continue
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set id [lindex $varcstart($v) $a]
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
if {[llength $children($v,$id)] > 1} {
set children($v,$id) [lsort -command [list vtokcmp $v] \
$children($v,$id)]
}
set oldtok [lindex $varctok($v) $a]
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
if {!$vdatemode($v)} {
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set tok {}
} else {
set tok $oldtok
}
set ka 0
gitk: Fix potential bug with fake commit IDs in renumbervarc When a fake row is added, we add its (fake) ID to the children list for its (fake) parent. If renumbervarc were to then renumber the parent it would incorrectly use the fake child. This avoids the problem by adding a last_real_child procedure which won't return a fake ID, and using it in renumbervarc. For symmetry this also adds a first_real_child procedure and uses it in ordertoken. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 03:54:58 +01:00
set kid [last_real_child $v,$id]
if {$kid ne {}} {
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set k $varcid($v,$kid)
if {[string compare [lindex $varctok($v) $k] $tok] > 0} {
set ki $kid
set ka $k
set tok [lindex $varctok($v) $k]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
if {$ka != 0} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set i [lsearch -exact $parents($v,$ki) $id]
set j [expr {[llength $parents($v,$ki)] - 1 - $i}]
append tok [strrep $j]
}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
if {$tok eq $oldtok} {
continue
}
set id [lindex $varccommits($v,$a) end]
foreach p $parents($v,$id) {
if {[info exists varcid($v,$p)]} {
set kidchanged($varcid($v,$p)) 1
} else {
set sortkids($p) 1
}
}
lset varctok($v) $a $tok
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set b [lindex $vupptr($v) $a]
if {$b != $ka} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
if {[string compare [lindex $varctok($v) $ka] $vtokmod($v)] < 0} {
modify_arc $v $ka
gitk: Fix bug in assigning row numbers to arcs We weren't setting vtokmod and varcmod in renumbervarc, so after a call to renumbervarc we sometimes weren't reassigning row numbers to all the arcs whose row numbers had changed. This fixes it. This also collapses layoutmore and showstuff into one procedure and gets rid of the phase variable. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-06 10:50:31 +01:00
}
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
if {[string compare [lindex $varctok($v) $b] $vtokmod($v)] < 0} {
modify_arc $v $b
gitk: Fix bug in assigning row numbers to arcs We weren't setting vtokmod and varcmod in renumbervarc, so after a call to renumbervarc we sometimes weren't reassigning row numbers to all the arcs whose row numbers had changed. This fixes it. This also collapses layoutmore and showstuff into one procedure and gets rid of the phase variable. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-06 10:50:31 +01:00
}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set c [lindex $vbackptr($v) $a]
set d [lindex $vleftptr($v) $a]
if {$c == 0} {
lset vdownptr($v) $b $d
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
} else {
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
lset vleftptr($v) $c $d
}
if {$d != 0} {
lset vbackptr($v) $d $c
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Fix bug where arcs could get lost Because we weren't fixing up vlastins when moving an arc from one place to another, it was possible for us later to decide to move an arc to the wrong place, and end up with an arc disconnected from the rest of the graph. This fixes it by updating vlastins when necessary. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-18 00:44:33 +01:00
if {[lindex $vlastins($v) $b] == $a} {
lset vlastins($v) $b $c
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
lset vupptr($v) $a $ka
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set c [lindex $vlastins($v) $ka]
if {$c == 0 || \
[string compare $tok [lindex $varctok($v) $c]] < 0} {
set c $ka
set b [lindex $vdownptr($v) $ka]
} else {
set b [lindex $vleftptr($v) $c]
}
while {$b != 0 && \
[string compare $tok [lindex $varctok($v) $b]] >= 0} {
set c $b
set b [lindex $vleftptr($v) $c]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
if {$c == $ka} {
lset vdownptr($v) $ka $a
lset vbackptr($v) $a 0
} else {
lset vleftptr($v) $c $a
lset vbackptr($v) $a $c
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
lset vleftptr($v) $a $b
if {$b != 0} {
lset vbackptr($v) $b $a
}
lset vlastins($v) $ka $a
}
}
foreach id [array names sortkids] {
if {[llength $children($v,$id)] > 1} {
set children($v,$id) [lsort -command [list vtokcmp $v] \
$children($v,$id)]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
}
set t2 [clock clicks -milliseconds]
#puts "renumbervarc did [llength $todo] of $ntot arcs in [expr {$t2-$t1}]ms"
}
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
# Fix up the graph after we have found out that in view $v,
# $p (a commit that we have already seen) is actually the parent
# of the last commit in arc $a.
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc fix_reversal {p a v} {
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
global varcid varcstart varctok vupptr
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set pa $varcid($v,$p)
if {$p ne [lindex $varcstart($v) $pa]} {
splitvarc $p $v
set pa $varcid($v,$p)
}
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
# seeds always need to be renumbered
if {[lindex $vupptr($v) $pa] == 0 ||
[string compare [lindex $varctok($v) $a] \
[lindex $varctok($v) $pa]] > 0} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
renumbervarc $pa $v
}
}
proc insertrow {id p v} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
global cmitlisted children parents varcid varctok vtokmod
global varccommits ordertok commitidx numcommits curview
global targetid targetrow
readcommit $id
set vid $v,$id
set cmitlisted($vid) 1
set children($vid) {}
set parents($vid) [list $p]
set a [newvarc $v $id]
set varcid($vid) $a
if {[string compare [lindex $varctok($v) $a] $vtokmod($v)] < 0} {
modify_arc $v $a
}
lappend varccommits($v,$a) $id
set vp $v,$p
if {[llength [lappend children($vp) $id]] > 1} {
set children($vp) [lsort -command [list vtokcmp $v] $children($vp)]
catch {unset ordertok}
}
fix_reversal $p $a $v
incr commitidx($v)
if {$v == $curview} {
set numcommits $commitidx($v)
setcanvscroll
if {[info exists targetid]} {
if {![comes_before $targetid $p]} {
incr targetrow
}
}
}
}
proc insertfakerow {id p} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
global varcid varccommits parents children cmitlisted
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
global commitidx varctok vtokmod targetid targetrow curview numcommits
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
set v $curview
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set a $varcid($v,$p)
set i [lsearch -exact $varccommits($v,$a) $p]
if {$i < 0} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
puts "oops: insertfakerow can't find [shortids $p] on arc $a"
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
return
}
set children($v,$id) {}
set parents($v,$id) [list $p]
set varcid($v,$id) $a
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
lappend children($v,$p) $id
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set cmitlisted($v,$id) 1
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
set numcommits [incr commitidx($v)]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
# note we deliberately don't update varcstart($v) even if $i == 0
set varccommits($v,$a) [linsert $varccommits($v,$a) $i $id]
gitk: Fix some corner cases in computing vrowmod and displayorder First, insertfakerow and removefakerow weren't updating vrowmod, and hence displayorder was not getting updated when it needed to, in the case where the fake row was being inserted into or removed from the last arc. The comparison of varctok vs vtokmod was moved into modify_arc for these cases (and for the call in rewrite_commit) to avoid duplicating the extra code needed. Second, the logic in update_arcrows didn't end up truncating displayorder and unsetting cached_commitrow if the first modified row was in the last arc. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:32:38 +01:00
modify_arc $v $a $i
gitk: Fix some corner cases in the targetid/targetrow stuff * Make sure targetrow is never >= numcommits * Don't try to do anything about the target row if the targetid is no longer in the view; it'll just cause Tcl errors * In insertrow, increment targetrow if we are inserting the fake commit at or before the target row * In removerow, if we are removing the target row, make it the next one instead. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-01 23:59:39 +01:00
if {[info exists targetid]} {
if {![comes_before $targetid $p]} {
incr targetrow
}
}
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
setcanvscroll
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
drawvisible
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
proc removefakerow {id} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
global varcid varccommits parents children commitidx
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
global varctok vtokmod cmitlisted currentid selectedline
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
global targetid curview numcommits
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
set v $curview
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[llength $parents($v,$id)] != 1} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
puts "oops: removefakerow [shortids $id] has [llength $parents($v,$id)] parents"
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
return
}
set p [lindex $parents($v,$id) 0]
set a $varcid($v,$id)
set i [lsearch -exact $varccommits($v,$a) $id]
if {$i < 0} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
puts "oops: removefakerow can't find [shortids $id] on arc $a"
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
return
}
unset varcid($v,$id)
set varccommits($v,$a) [lreplace $varccommits($v,$a) $i $i]
unset parents($v,$id)
unset children($v,$id)
unset cmitlisted($v,$id)
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
set numcommits [incr commitidx($v) -1]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set j [lsearch -exact $children($v,$p) $id]
if {$j >= 0} {
set children($v,$p) [lreplace $children($v,$p) $j $j]
}
gitk: Fix some corner cases in computing vrowmod and displayorder First, insertfakerow and removefakerow weren't updating vrowmod, and hence displayorder was not getting updated when it needed to, in the case where the fake row was being inserted into or removed from the last arc. The comparison of varctok vs vtokmod was moved into modify_arc for these cases (and for the call in rewrite_commit) to avoid duplicating the extra code needed. Second, the logic in update_arcrows didn't end up truncating displayorder and unsetting cached_commitrow if the first modified row was in the last arc. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:32:38 +01:00
modify_arc $v $a $i
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
if {[info exist currentid] && $id eq $currentid} {
unset currentid
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
set selectedline {}
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
}
gitk: Fix some corner cases in the targetid/targetrow stuff * Make sure targetrow is never >= numcommits * Don't try to do anything about the target row if the targetid is no longer in the view; it'll just cause Tcl errors * In insertrow, increment targetrow if we are inserting the fake commit at or before the target row * In removerow, if we are removing the target row, make it the next one instead. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-01 23:59:39 +01:00
if {[info exists targetid] && $targetid eq $id} {
set targetid $p
}
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
setcanvscroll
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
drawvisible
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Fix potential bug with fake commit IDs in renumbervarc When a fake row is added, we add its (fake) ID to the children list for its (fake) parent. If renumbervarc were to then renumber the parent it would incorrectly use the fake child. This avoids the problem by adding a last_real_child procedure which won't return a fake ID, and using it in renumbervarc. For symmetry this also adds a first_real_child procedure and uses it in ordertoken. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 03:54:58 +01:00
proc first_real_child {vp} {
global children nullid nullid2
foreach id $children($vp) {
if {$id ne $nullid && $id ne $nullid2} {
return $id
}
}
return {}
}
proc last_real_child {vp} {
global children nullid nullid2
set kids $children($vp)
for {set i [llength $kids]} {[incr i -1] >= 0} {} {
set id [lindex $kids $i]
if {$id ne $nullid && $id ne $nullid2} {
return $id
}
}
return {}
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc vtokcmp {v a b} {
global varctok varcid
return [string compare [lindex $varctok($v) $varcid($v,$a)] \
[lindex $varctok($v) $varcid($v,$b)]]
}
gitk: Fix some corner cases in computing vrowmod and displayorder First, insertfakerow and removefakerow weren't updating vrowmod, and hence displayorder was not getting updated when it needed to, in the case where the fake row was being inserted into or removed from the last arc. The comparison of varctok vs vtokmod was moved into modify_arc for these cases (and for the call in rewrite_commit) to avoid duplicating the extra code needed. Second, the logic in update_arcrows didn't end up truncating displayorder and unsetting cached_commitrow if the first modified row was in the last arc. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:32:38 +01:00
# This assumes that if lim is not given, the caller has checked that
# arc a's token is less than $vtokmod($v)
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
proc modify_arc {v a {lim {}}} {
global varctok vtokmod varcmod varcrow vupptr curview vrowmod varccommits
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
gitk: Fix some corner cases in computing vrowmod and displayorder First, insertfakerow and removefakerow weren't updating vrowmod, and hence displayorder was not getting updated when it needed to, in the case where the fake row was being inserted into or removed from the last arc. The comparison of varctok vs vtokmod was moved into modify_arc for these cases (and for the call in rewrite_commit) to avoid duplicating the extra code needed. Second, the logic in update_arcrows didn't end up truncating displayorder and unsetting cached_commitrow if the first modified row was in the last arc. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:32:38 +01:00
if {$lim ne {}} {
set c [string compare [lindex $varctok($v) $a] $vtokmod($v)]
if {$c > 0} return
if {$c == 0} {
set r [lindex $varcrow($v) $a]
if {$r ne {} && $vrowmod($v) <= $r + $lim} return
}
}
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
set vtokmod($v) [lindex $varctok($v) $a]
set varcmod($v) $a
if {$v == $curview} {
while {$a != 0 && [lindex $varcrow($v) $a] eq {}} {
set a [lindex $vupptr($v) $a]
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
set lim {}
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
}
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
set r 0
if {$a != 0} {
if {$lim eq {}} {
set lim [llength $varccommits($v,$a)]
}
set r [expr {[lindex $varcrow($v) $a] + $lim}]
}
set vrowmod($v) $r
gitk: Fix a couple of bugs First, if we invalidate the layout for all rows (i.e. from row 0 on), we were calling undolayout with an empty string as the argument. Second, the comparison in make_disporder that tests if we need to call update_arcrows was the wrong way around. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 10:09:53 +01:00
undolayout $r
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
}
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc update_arcrows {v} {
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
global vtokmod varcmod vrowmod varcrow commitidx currentid selectedline
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
global varcid vrownum varcorder varcix varccommits
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global vupptr vdownptr vleftptr varctok
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
global displayorder parentlist curview cached_commitrow
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
gitk: Fix some corner cases in computing vrowmod and displayorder First, insertfakerow and removefakerow weren't updating vrowmod, and hence displayorder was not getting updated when it needed to, in the case where the fake row was being inserted into or removed from the last arc. The comparison of varctok vs vtokmod was moved into modify_arc for these cases (and for the call in rewrite_commit) to avoid duplicating the extra code needed. Second, the logic in update_arcrows didn't end up truncating displayorder and unsetting cached_commitrow if the first modified row was in the last arc. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:32:38 +01:00
if {$vrowmod($v) == $commitidx($v)} return
if {$v == $curview} {
if {[llength $displayorder] > $vrowmod($v)} {
set displayorder [lrange $displayorder 0 [expr {$vrowmod($v) - 1}]]
set parentlist [lrange $parentlist 0 [expr {$vrowmod($v) - 1}]]
}
catch {unset cached_commitrow}
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set narctot [expr {[llength $varctok($v)] - 1}]
set a $varcmod($v)
while {$a != 0 && [lindex $varcix($v) $a] eq {}} {
# go up the tree until we find something that has a row number,
# or we get to a seed
set a [lindex $vupptr($v) $a]
}
if {$a == 0} {
set a [lindex $vdownptr($v) 0]
if {$a == 0} return
set vrownum($v) {0}
set varcorder($v) [list $a]
lset varcix($v) $a 0
lset varcrow($v) $a 0
set arcn 0
set row 0
} else {
set arcn [lindex $varcix($v) $a]
if {[llength $vrownum($v)] > $arcn + 1} {
set vrownum($v) [lrange $vrownum($v) 0 $arcn]
set varcorder($v) [lrange $varcorder($v) 0 $arcn]
}
set row [lindex $varcrow($v) $a]
}
while {1} {
set p $a
incr row [llength $varccommits($v,$a)]
# go down if possible
set b [lindex $vdownptr($v) $a]
if {$b == 0} {
# if not, go left, or go up until we can go left
while {$a != 0} {
set b [lindex $vleftptr($v) $a]
if {$b != 0} break
set a [lindex $vupptr($v) $a]
}
if {$a == 0} break
}
set a $b
incr arcn
lappend vrownum($v) $row
lappend varcorder($v) $a
lset varcix($v) $a $arcn
lset varcrow($v) $a $row
}
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
set vtokmod($v) [lindex $varctok($v) $p]
set varcmod($v) $p
set vrowmod($v) $row
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[info exists currentid]} {
set selectedline [rowofcommit $currentid]
}
}
# Test whether view $v contains commit $id
proc commitinview {id v} {
global varcid
return [info exists varcid($v,$id)]
}
# Return the row number for commit $id in the current view
proc rowofcommit {id} {
global varcid varccommits varcrow curview cached_commitrow
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
global varctok vtokmod
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set v $curview
if {![info exists varcid($v,$id)]} {
puts "oops rowofcommit no arc for [shortids $id]"
return {}
}
set a $varcid($v,$id)
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
if {[string compare [lindex $varctok($v) $a] $vtokmod($v)] >= 0} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
update_arcrows $v
}
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
if {[info exists cached_commitrow($id)]} {
return $cached_commitrow($id)
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set i [lsearch -exact $varccommits($v,$a) $id]
if {$i < 0} {
puts "oops didn't find commit [shortids $id] in arc $a"
return {}
}
incr i [lindex $varcrow($v) $a]
set cached_commitrow($id) $i
return $i
}
gitk: Fix some corner cases in the targetid/targetrow stuff * Make sure targetrow is never >= numcommits * Don't try to do anything about the target row if the targetid is no longer in the view; it'll just cause Tcl errors * In insertrow, increment targetrow if we are inserting the fake commit at or before the target row * In removerow, if we are removing the target row, make it the next one instead. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-01 23:59:39 +01:00
# Returns 1 if a is on an earlier row than b, otherwise 0
proc comes_before {a b} {
global varcid varctok curview
set v $curview
if {$a eq $b || ![info exists varcid($v,$a)] || \
![info exists varcid($v,$b)]} {
return 0
}
if {$varcid($v,$a) != $varcid($v,$b)} {
return [expr {[string compare [lindex $varctok($v) $varcid($v,$a)] \
[lindex $varctok($v) $varcid($v,$b)]] < 0}]
}
return [expr {[rowofcommit $a] < [rowofcommit $b]}]
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc bsearch {l elt} {
if {[llength $l] == 0 || $elt <= [lindex $l 0]} {
return 0
}
set lo 0
set hi [llength $l]
while {$hi - $lo > 1} {
set mid [expr {int(($lo + $hi) / 2)}]
set t [lindex $l $mid]
if {$elt < $t} {
set hi $mid
} elseif {$elt > $t} {
set lo $mid
} else {
return $mid
}
}
return $lo
}
# Make sure rows $start..$end-1 are valid in displayorder and parentlist
proc make_disporder {start end} {
global vrownum curview commitidx displayorder parentlist
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
global varccommits varcorder parents vrowmod varcrow
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global d_valid_start d_valid_end
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
if {$end > $vrowmod($curview)} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
update_arcrows $curview
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set ai [bsearch $vrownum($curview) $start]
set start [lindex $vrownum($curview) $ai]
set narc [llength $vrownum($curview)]
for {set r $start} {$ai < $narc && $r < $end} {incr ai} {
set a [lindex $varcorder($curview) $ai]
set l [llength $displayorder]
set al [llength $varccommits($curview,$a)]
if {$l < $r + $al} {
if {$l < $r} {
set pad [ntimes [expr {$r - $l}] {}]
set displayorder [concat $displayorder $pad]
set parentlist [concat $parentlist $pad]
} elseif {$l > $r} {
set displayorder [lrange $displayorder 0 [expr {$r - 1}]]
set parentlist [lrange $parentlist 0 [expr {$r - 1}]]
}
foreach id $varccommits($curview,$a) {
lappend displayorder $id
lappend parentlist $parents($curview,$id)
}
gitk: Fix a bug in make_disporder The make_disporder function has an optimization where it assumed that if displayorder was already long enough and the first entry in it for a particular arc was non-null, then the whole arc was present. This turns out not to be true in some circumstances, since we can add a commit to an arc (which truncates displayorder to the previous end of that arc), then call make_disporder for later arcs (which will pad displayorder with null elements), then call make_disporder for the first arc - which won't update the null elements. This fixes it by changing the optimization to check the last element for the arc instead of the first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-12 11:46:31 +01:00
} elseif {[lindex $displayorder [expr {$r + $al - 1}]] eq {}} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set i $r
foreach id $varccommits($curview,$a) {
lset displayorder $i $id
lset parentlist $i $parents($curview,$id)
incr i
}
}
incr r $al
}
}
proc commitonrow {row} {
global displayorder
set id [lindex $displayorder $row]
if {$id eq {}} {
make_disporder $row [expr {$row + 1}]
set id [lindex $displayorder $row]
}
return $id
}
proc closevarcs {v} {
global varctok varccommits varcid parents children
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
global cmitlisted commitidx vtokmod
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set missing_parents 0
set scripts {}
set narcs [llength $varctok($v)]
for {set a 1} {$a < $narcs} {incr a} {
set id [lindex $varccommits($v,$a) end]
foreach p $parents($v,$id) {
if {[info exists varcid($v,$p)]} continue
# add p as a new commit
incr missing_parents
set cmitlisted($v,$p) 0
set parents($v,$p) {}
if {[llength $children($v,$p)] == 1 &&
[llength $parents($v,$id)] == 1} {
set b $a
} else {
set b [newvarc $v $p]
}
set varcid($v,$p) $b
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
if {[string compare [lindex $varctok($v) $b] $vtokmod($v)] < 0} {
modify_arc $v $b
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
lappend varccommits($v,$b) $p
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
incr commitidx($v)
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
set scripts [check_interest $p $scripts]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
}
if {$missing_parents > 0} {
foreach s $scripts {
eval $s
}
}
}
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
# Use $rwid as a substitute for $id, i.e. reparent $id's children to $rwid
# Assumes we already have an arc for $rwid.
proc rewrite_commit {v id rwid} {
global children parents varcid varctok vtokmod varccommits
foreach ch $children($v,$id) {
# make $rwid be $ch's parent in place of $id
set i [lsearch -exact $parents($v,$ch) $id]
if {$i < 0} {
puts "oops rewrite_commit didn't find $id in parent list for $ch"
}
set parents($v,$ch) [lreplace $parents($v,$ch) $i $i $rwid]
# add $ch to $rwid's children and sort the list if necessary
if {[llength [lappend children($v,$rwid) $ch]] > 1} {
set children($v,$rwid) [lsort -command [list vtokcmp $v] \
$children($v,$rwid)]
}
# fix the graph after joining $id to $rwid
set a $varcid($v,$ch)
fix_reversal $rwid $a $v
gitk: Fix some corner cases in computing vrowmod and displayorder First, insertfakerow and removefakerow weren't updating vrowmod, and hence displayorder was not getting updated when it needed to, in the case where the fake row was being inserted into or removed from the last arc. The comparison of varctok vs vtokmod was moved into modify_arc for these cases (and for the call in rewrite_commit) to avoid duplicating the extra code needed. Second, the logic in update_arcrows didn't end up truncating displayorder and unsetting cached_commitrow if the first modified row was in the last arc. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:32:38 +01:00
# parentlist is wrong for the last element of arc $a
# even if displayorder is right, hence the 3rd arg here
modify_arc $v $a [expr {[llength $varccommits($v,$a)] - 1}]
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
}
}
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
# Mechanism for registering a command to be executed when we come
# across a particular commit. To handle the case when only the
# prefix of the commit is known, the commitinterest array is now
# indexed by the first 4 characters of the ID. Each element is a
# list of id, cmd pairs.
proc interestedin {id cmd} {
global commitinterest
lappend commitinterest([string range $id 0 3]) $id $cmd
}
proc check_interest {id scripts} {
global commitinterest
set prefix [string range $id 0 3]
if {[info exists commitinterest($prefix)]} {
set newlist {}
foreach {i script} $commitinterest($prefix) {
if {[string match "$i*" $id]} {
lappend scripts [string map [list "%I" $id "%P" $i] $script]
} else {
lappend newlist $i $script
}
}
if {$newlist ne {}} {
set commitinterest($prefix) $newlist
} else {
unset commitinterest($prefix)
}
}
return $scripts
}
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
proc getcommitlines {fd inst view updating} {
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
global cmitlisted leftover
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
global commitidx commitdata vdatemode
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global parents children curview hlview
gitk: Don't filter view arguments through git rev-parse Previously we passed the arguments indicating what commits the user wants to view through git rev-parse to get a list of IDs (positive and negative), then gave that to git log. This had a couple of problems, notably that --merge and --left-right didn't get handled properly. Instead we now just pass the original arguments to git log. When doing an update, we append --not followed by the list of commits we have seen that have no children, since we have got (or will get) their ancestors from the first git log. If the first git log isn't finished yet, we might get some duplicates from the second git log, but that doesn't cause any problem. Also get rid of the unused vnextroot variable. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:19:35 +01:00
global idpending ordertok
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
global varccommits varcid varctok vtokmod vfilelimit
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
gitk: Improve responsiveness while reading and layout out the graph This restructures layoutmore so that it can take a time limit and do limited amounts of graph layout and graph optimization, and return 1 if it exceeded the time limit before finishing everything it could do. Also getcommitlines reads at most half a megabyte each time, to limit the time it spends parsing the commits to about a tenth of a second. Also got rid of the unused ncmupdate variable while I was at it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-16 12:02:32 +02:00
set stuff [read $fd 500000]
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
# git log doesn't terminate the last commit with a null...
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$stuff == {} && $leftover($inst) ne {} && [eof $fd]} {
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
set stuff "\0"
}
Use git-rev-list --header. With --header, git-rev-list gives us the contents of the commit in-line, so we don't need to exec a git-cat-file to get it, and we don't need the readobj command either. Also fixed a residual problem with handling the commit that has a parent listed twice.
2005-06-22 02:25:38 +02:00
if {$stuff == {}} {
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
if {![eof $fd]} {
return 1
}
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
global commfd viewcomplete viewactive viewname
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global viewinstances
unset commfd($inst)
set i [lsearch -exact $viewinstances($view) $inst]
if {$i >= 0} {
set viewinstances($view) [lreplace $viewinstances($view) $i $i]
gitk: Get rid of idinlist array This changes layoutrows to use information from rowidlist and children to work out which parent ids are appearing for the first time or need an up arrow, instead of using idinlist. To detect the situation where git log doesn't give us all the commits it references, this adds an idpending array that is updated and used by getcommitlines. This also fixes a bug where we weren't resetting the ordertok array when updating the list of commits; this fixes that too, and a bug where we could try to access an undefined element of commitrow if the user did an update before gitk had finished reading in the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 11:35:51 +02:00
}
Make the diff display less gaudy. The old style is still available as an option (we still need a preferences window so we can set/clear it though).
2005-07-18 20:29:03 +02:00
# set it blocking so we wait for the process to terminate
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
fconfigure $fd -blocking 1
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
if {[catch {close $fd} err]} {
set fv {}
if {$view != $curview} {
set fv " for the \"$viewname($view)\" view"
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
if {[string range $err 0 4] == "usage"} {
set err "Gitk: error reading commits$fv:\
gitk: Correct a few strings and comments to say "git log" ... instead of "git rev-list", since we now use git log for generating the list of commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:14:17 +01:00
bad arguments to git log."
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
if {$viewname($view) eq "Command line"} {
append err \
gitk: Correct a few strings and comments to say "git log" ... instead of "git rev-list", since we now use git log for generating the list of commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:14:17 +01:00
" (Note: arguments to gitk are passed to git log\
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
to allow selection of commits to be displayed.)"
}
} else {
set err "Error reading commits$fv: $err"
}
error_popup $err
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[incr viewactive($view) -1] <= 0} {
set viewcomplete($view) 1
# Check if we have seen any ids listed as parents that haven't
# appeared in the list
closevarcs $view
notbusy $view
}
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
if {$view == $curview} {
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
run chewcommits
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
}
Use git-rev-list --header. With --header, git-rev-list gives us the contents of the commit in-line, so we don't need to exec a git-cat-file to get it, and we don't need the readobj command either. Also fixed a residual problem with handling the commit that has a parent listed twice.
2005-06-22 02:25:38 +02:00
set start 0
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
set gotsome 0
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set scripts {}
Use git-rev-list --header. With --header, git-rev-list gives us the contents of the commit in-line, so we don't need to exec a git-cat-file to get it, and we don't need the readobj command either. Also fixed a residual problem with handling the commit that has a parent listed twice.
2005-06-22 02:25:38 +02:00
while 1 {
set i [string first "\0" $stuff $start]
if {$i < 0} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
append leftover($inst) [string range $stuff $start end]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
break
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
}
Use git-rev-list --header. With --header, git-rev-list gives us the contents of the commit in-line, so we don't need to exec a git-cat-file to get it, and we don't need the readobj command either. Also fixed a residual problem with handling the commit that has a parent listed twice.
2005-06-22 02:25:38 +02:00
if {$start == 0} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set cmit $leftover($inst)
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
append cmit [string range $stuff 0 [expr {$i - 1}]]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set leftover($inst) {}
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
} else {
set cmit [string range $stuff $start [expr {$i - 1}]]
Use git-rev-list --header. With --header, git-rev-list gives us the contents of the commit in-line, so we don't need to exec a git-cat-file to get it, and we don't need the readobj command either. Also fixed a residual problem with handling the commit that has a parent listed twice.
2005-06-22 02:25:38 +02:00
}
set start [expr {$i + 1}]
Use the --parents flag to git-rev-list. With --parents, git-rev-list gives us the list of parents on the first line of each commit. We use that rather than looking for the parent: lines in the commit body, since this way we get to know about the grafts for free.
2005-08-18 12:40:39 +02:00
set j [string first "\n" $cmit]
set ok 0
gitk: Use the new --boundary flag to git-rev-list With this, we can show the boundary (open-circle) commits immediately after their last child, which looks much better than putting all the boundary commits at the bottom of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-30 09:43:51 +02:00
set listed 1
gitk: Use git log and add support for --left-right This is based on patches from Linus Torvalds and Junio Hamano, so the ideas here are theirs. This makes gitk use "git log -z --pretty=raw" instead of "git rev-list" to generate the list of commits, and also makes it grok the "<" and ">" markers that git log (and git rev-list) output with the --left-right flag to indicate which side of a symmetric diff a commit is reachable from. Left-side commits are drawn with a triangle pointing leftwards instead of a circle, and right-side commits are drawn with a triangle pointing rightwards. The commitlisted list is used to store the left/right information as well as the information about whether each commit is on the boundary. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-09 14:45:47 +02:00
if {$j >= 0 && [string match "commit *" $cmit]} {
set ids [string range $cmit 7 [expr {$j - 1}]]
[PATCH] gitk: learn --show-all output It's really not very easy to visualize the commit walker, because - on purpose - it obvously doesn't show the uninteresting commits! We will soon add a "--show-all" flag to the revision walker, which will make it show uninteresting commits too, and they'll have a '^' in front of them. This is to update 'gitk' to show those negative commits in gray to futureproof it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-09 23:02:07 +01:00
if {[string match {[-^<>]*} $ids]} {
gitk: Use git log and add support for --left-right This is based on patches from Linus Torvalds and Junio Hamano, so the ideas here are theirs. This makes gitk use "git log -z --pretty=raw" instead of "git rev-list" to generate the list of commits, and also makes it grok the "<" and ">" markers that git log (and git rev-list) output with the --left-right flag to indicate which side of a symmetric diff a commit is reachable from. Left-side commits are drawn with a triangle pointing leftwards instead of a circle, and right-side commits are drawn with a triangle pointing rightwards. The commitlisted list is used to store the left/right information as well as the information about whether each commit is on the boundary. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-09 14:45:47 +02:00
switch -- [string index $ids 0] {
"-" {set listed 0}
[PATCH] gitk: learn --show-all output It's really not very easy to visualize the commit walker, because - on purpose - it obvously doesn't show the uninteresting commits! We will soon add a "--show-all" flag to the revision walker, which will make it show uninteresting commits too, and they'll have a '^' in front of them. This is to update 'gitk' to show those negative commits in gray to futureproof it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-09 23:02:07 +01:00
"^" {set listed 2}
"<" {set listed 3}
">" {set listed 4}
gitk: Use git log and add support for --left-right This is based on patches from Linus Torvalds and Junio Hamano, so the ideas here are theirs. This makes gitk use "git log -z --pretty=raw" instead of "git rev-list" to generate the list of commits, and also makes it grok the "<" and ">" markers that git log (and git rev-list) output with the --left-right flag to indicate which side of a symmetric diff a commit is reachable from. Left-side commits are drawn with a triangle pointing leftwards instead of a circle, and right-side commits are drawn with a triangle pointing rightwards. The commitlisted list is used to store the left/right information as well as the information about whether each commit is on the boundary. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-09 14:45:47 +02:00
}
gitk: Use the new --boundary flag to git-rev-list With this, we can show the boundary (open-circle) commits immediately after their last child, which looks much better than putting all the boundary commits at the bottom of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-30 09:43:51 +02:00
set ids [string range $ids 1 end]
}
Use the --parents flag to git-rev-list. With --parents, git-rev-list gives us the list of parents on the first line of each commit. We use that rather than looking for the parent: lines in the commit body, since this way we get to know about the grafts for free.
2005-08-18 12:40:39 +02:00
set ok 1
foreach id $ids {
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
if {[string length $id] != 40} {
Use the --parents flag to git-rev-list. With --parents, git-rev-list gives us the list of parents on the first line of each commit. We use that rather than looking for the parent: lines in the commit body, since this way we get to know about the grafts for free.
2005-08-18 12:40:39 +02:00
set ok 0
break
}
}
}
if {!$ok} {
Fix a bug where we would corrupt the stuff read from git-rev-list. If we have a very long commit message, and we end up getting a bufferfull of data from git-rev-list that all belongs to one commit, we ended up throwing away the data from a previous read that should have been included. The result was a error message about not being able to parse the output of git-rev-list. Also, if the git-rev-list output that we can't parse is long, only put the first 80 chars in the error message. Otherwise we end up with an enormous error window.
2005-06-27 12:04:26 +02:00
set shortcmit $cmit
if {[string length $shortcmit] > 80} {
set shortcmit "[string range $shortcmit 0 80]..."
}
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
error_popup "[mc "Can't parse git log output:"] {$shortcmit}"
Use git-rev-list --header. With --header, git-rev-list gives us the contents of the commit in-line, so we don't need to exec a git-cat-file to get it, and we don't need the readobj command either. Also fixed a residual problem with handling the commit that has a parent listed twice.
2005-06-22 02:25:38 +02:00
exit 1
}
Use the --parents flag to git-rev-list. With --parents, git-rev-list gives us the list of parents on the first line of each commit. We use that rather than looking for the parent: lines in the commit body, since this way we get to know about the grafts for free.
2005-08-18 12:40:39 +02:00
set id [lindex $ids 0]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set vid $view,$id
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
if {!$listed && $updating && ![info exists varcid($vid)] &&
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
$vfilelimit($view) ne {}} {
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
# git log doesn't rewrite parents for unlisted commits
# when doing path limiting, so work around that here
# by working out the rewritten parent with git rev-list
# and if we already know about it, using the rewritten
# parent as a substitute parent for $id's children.
if {![catch {
set rwid [exec git rev-list --first-parent --max-count=1 \
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
$id -- $vfilelimit($view)]
gitk: Handle updating with path limiting better When updating the graph, gitk uses a git log command with commit limiting in order to get just the new commits. When path limiting is also in effect, git log rewrites the parents of the commits it outputs in order to represent just the subgraph that modifies the listed paths, but it doesn't rewrite the parents on the boundary of the graph. The result is that when updating, git log does not give gitk the information about where the new commits join in to the existing graph. This solves the problem by explicitly rewriting boundary parents when updating. If we are updating and are doing path limiting, then when gitk finds an unlisted commit (one where git log puts a "-" in front of the commit ID to indicate that it isn't actually part of the graph), then gitk will execute: git rev-list --first-parent --max-count=1 $id -- paths... which returns the first ancestor that affects the listed paths. (Currently gitk executes this synchronously; it could do it asynchronously, which would be more complex but would avoid the possibility of the UI freezing up if git rev-list takes a long time.) Then, if the result is a commit that we know about, we rewrite the parents of the children of the original commit to point to the new commit. That is mostly a matter of adjusting the parents and children arrays and calling fix_reversal to fix up the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-24 02:16:56 +01:00
}]} {
if {$rwid ne {} && [info exists varcid($view,$rwid)]} {
# use $rwid in place of $id
rewrite_commit $view $id $rwid
continue
}
}
}
gitk: Cope better with getting commits that we have already seen This fixes a bug in updating the graph after we have cherry-picked a commit in gitk and then added some new stuff externally. First, we weren't updating viewincl with the new head added by the cherry- pick. Secondly, getcommitlines was doing bad things if it saw a commit that was already in the graph (was already in an arc). This fixes both things. If getcommitlines sees a commit that is already in the graph, it ignores it unless it was not listed before and is listed now. In that case it doesn't assign it a new arc now, and doesn't re-add the commit to its arc. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-16 07:47:31 +01:00
set a 0
if {[info exists varcid($vid)]} {
if {$cmitlisted($vid) || !$listed} continue
set a $varcid($vid)
}
gitk: Use the new --boundary flag to git-rev-list With this, we can show the boundary (open-circle) commits immediately after their last child, which looks much better than putting all the boundary commits at the bottom of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-30 09:43:51 +02:00
if {$listed} {
set olds [lrange $ids 1 end]
} else {
set olds {}
}
gitk: Make commitdata an array rather than a list This turns out to be slightly simpler and faster, and will make things a little easier when we do multiple view support. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 00:04:48 +01:00
set commitdata($id) [string range $cmit [expr {$j + 1}] end]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set cmitlisted($vid) $listed
set parents($vid) $olds
if {![info exists children($vid)]} {
set children($vid) {}
gitk: Cope better with getting commits that we have already seen This fixes a bug in updating the graph after we have cherry-picked a commit in gitk and then added some new stuff externally. First, we weren't updating viewincl with the new head added by the cherry- pick. Secondly, getcommitlines was doing bad things if it saw a commit that was already in the graph (was already in an arc). This fixes both things. If getcommitlines sees a commit that is already in the graph, it ignores it unless it was not listed before and is listed now. In that case it doesn't assign it a new arc now, and doesn't re-add the commit to its arc. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-16 07:47:31 +01:00
} elseif {$a == 0 && [llength $children($vid)] == 1} {
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
set k [lindex $children($vid) 0]
if {[llength $parents($view,$k)] == 1 &&
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
(!$vdatemode($view) ||
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
$varcid($view,$k) == [llength $varctok($view)] - 1)} {
set a $varcid($view,$k)
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$a == 0} {
# new arc
set a [newvarc $view $id]
}
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
if {[string compare [lindex $varctok($view) $a] $vtokmod($view)] < 0} {
modify_arc $view $a
}
gitk: Cope better with getting commits that we have already seen This fixes a bug in updating the graph after we have cherry-picked a commit in gitk and then added some new stuff externally. First, we weren't updating viewincl with the new head added by the cherry- pick. Secondly, getcommitlines was doing bad things if it saw a commit that was already in the graph (was already in an arc). This fixes both things. If getcommitlines sees a commit that is already in the graph, it ignores it unless it was not listed before and is listed now. In that case it doesn't assign it a new arc now, and doesn't re-add the commit to its arc. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-16 07:47:31 +01:00
if {![info exists varcid($vid)]} {
set varcid($vid) $a
lappend varccommits($view,$a) $id
incr commitidx($view)
}
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set i 0
foreach p $olds {
if {$i == 0 || [lsearch -exact $olds $p] >= $i} {
set vp $view,$p
if {[llength [lappend children($vp) $id]] > 1 &&
[vtokcmp $view [lindex $children($vp) end-1] $id] > 0} {
set children($vp) [lsort -command [list vtokcmp $view] \
$children($vp)]
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
catch {unset ordertok}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Implement date mode in the new framework This restores date mode, which lists commits by date, as far as possible given the constraint that parents come after all their children. To implement this in the new framework, we (1) only join a new commit onto an existing arc if the arc is the last arc created, (2) treat arcs as seeds unless they have a child arc that comes later, and (3) never decrease the token value for an arc. This means we get lots of "seeds", which exposed some quadratic behaviour in adding and removing seeds. To fix this, we add a vbackptr array, which points to the arc whose vleftptr entry points to us, and a vlastins array, which shows where in an arc's vdownptr/vleftptr list we last inserted a parent, which acts as a hint of a good place to start looking for where to insert a new child. This also ensures the children array elements stay in sorted order at all times. We weren't resorting the children lists when reassigning tokens in renumbervarc. Since the children lists are now always sorted, we don't have to search through all elements to find the one with the highest token; we can just use the last element. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-20 00:03:35 +01:00
if {[info exists varcid($view,$p)]} {
fix_reversal $p $a $view
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
incr i
}
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
set scripts [check_interest $id $scripts]
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
set gotsome 1
}
if {$gotsome} {
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
global numcommits hlview
if {$view == $curview} {
set numcommits $commitidx($view)
run chewcommits
}
if {[info exists hlview] && $view == $hlview} {
# we never actually get here...
run vhighlightmore
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
foreach s $scripts {
eval $s
}
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 2
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
}
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
proc chewcommits {} {
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
global curview hlview viewcomplete
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global pending_select
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
layoutmore
if {$viewcomplete($curview)} {
global commitidx varctok
global numcommits startmsecs
if {[info exists pending_select]} {
gitk: Fallback to selecting the head commit upon load Try selecting the head, if the previously selected commit is not available in the new view. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:15:54 +02:00
update
reset_pending_select {}
if {[commitinview $pending_select $curview]} {
selectline [rowofcommit $pending_select] 1
} else {
set row [first_real_row]
selectline $row 1
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
}
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
if {$commitidx($curview) > 0} {
#set ms [expr {[clock clicks -milliseconds] - $startmsecs}]
#puts "overall $ms ms for $numcommits commits"
#puts "[llength $varctok($view)] arcs, $commitidx($view) commits"
} else {
show_status [mc "No commits selected"]
}
notbusy layout
Refine the update heuristic to improve responsiveness a bit. The previous commit improved performance a lot but also meant that we waited longer to see something drawn. This refines the heuristics for when to call update so that (1) when we have finished processing a bufferfull of information from git-rev-list, we call update if enough time has elapsed, regardless of how many commits we've drawn, and (2) the number of commits drawn between updates scales with the total number of commits drawn: 1 for 1-99 commits, 10 for 100-9999 commits, or 100 for >= 10000 commits.
2005-08-11 01:56:23 +02:00
}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
return 0
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
}
gitk: Fix commit encoding support This commit fixes two problems with commit encodings: 1) git-log actually uses i18n.logoutputencoding to generate its output, and falls back to i18n.commitencoding only when that option is not set. Thus, gitk should use its value to read the results, if available. 2) The readcommit function did not process encodings at all. This led to randomly appearing misconverted commits if the commit encoding differed from the current locale. Now commit messages should be displayed correctly, except when logoutputencoding is set to an encoding that cannot represent charecters in the message. For example, it is impossible to convert Japanese characters from Shift-JIS to CP-1251 (although the reverse conversion works). The reason for using git log to read the commit and then getting Tcl to convert its output is that is essentially what happens in the normal path through getcommitlines, hence there is less chance for unintended differences in how commits are processed in getcommitlines and do_readcommit. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 16:06:07 +01:00
proc do_readcommit {id} {
global tclencoding
# Invoke git-log to handle automatic encoding conversion
set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]
# Read the results using i18n.logoutputencoding
fconfigure $fd -translation lf -eofchar {}
if {$tclencoding != {}} {
fconfigure $fd -encoding $tclencoding
}
set contents [read $fd]
close $fd
# Remove the heading line
regsub {^commit [0-9a-f]+\n} $contents {} contents
return $contents
}
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
proc readcommit {id} {
gitk: Fix commit encoding support This commit fixes two problems with commit encodings: 1) git-log actually uses i18n.logoutputencoding to generate its output, and falls back to i18n.commitencoding only when that option is not set. Thus, gitk should use its value to read the results, if available. 2) The readcommit function did not process encodings at all. This led to randomly appearing misconverted commits if the commit encoding differed from the current locale. Now commit messages should be displayed correctly, except when logoutputencoding is set to an encoding that cannot represent charecters in the message. For example, it is impossible to convert Japanese characters from Shift-JIS to CP-1251 (although the reverse conversion works). The reason for using git log to read the commit and then getting Tcl to convert its output is that is essentially what happens in the normal path through getcommitlines, hence there is less chance for unintended differences in how commits are processed in getcommitlines and do_readcommit. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 16:06:07 +01:00
if {[catch {set contents [do_readcommit $id]}]} return
parsecommit $id $contents 1
Use git-rev-list --header. With --header, git-rev-list gives us the contents of the commit in-line, so we don't need to exec a git-cat-file to get it, and we don't need the readobj command either. Also fixed a residual problem with handling the commit that has a parent listed twice.
2005-06-22 02:25:38 +02:00
}
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
proc parsecommit {id contents listed} {
[PATCH] gitk: add Update menu item. Update will redraw the commits if any commits have been added to any of the selected heads. The new commits appear on the top. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 22:15:51 +01:00
global commitinfo cdate
set inhdr 1
set comment {}
set headline {}
set auname {}
set audate {}
set comname {}
set comdate {}
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set hdrend [string first "\n\n" $contents]
if {$hdrend < 0} {
# should never happen...
set hdrend [string length $contents]
}
set header [string range $contents 0 [expr {$hdrend - 1}]]
set comment [string range $contents [expr {$hdrend + 2}] end]
foreach line [split $header "\n"] {
gitk: Allow unbalanced quotes/braces in commit headers When parsing commits, gitk treats the headers of the commit as tcl lists. This causes errors if the header contains an unbalanced quote or open brace. Splitting the line on spaces allows us to treat it as a set of words instead of as a tcl list, which prevents errors. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-18 10:26:48 +01:00
set line [split $line " "]
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set tag [lindex $line 0]
if {$tag == "author"} {
set audate [lindex $line end-1]
gitk: Allow unbalanced quotes/braces in commit headers When parsing commits, gitk treats the headers of the commit as tcl lists. This causes errors if the header contains an unbalanced quote or open brace. Splitting the line on spaces allows us to treat it as a set of words instead of as a tcl list, which prevents errors. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-18 10:26:48 +01:00
set auname [join [lrange $line 1 end-2] " "]
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
} elseif {$tag == "committer"} {
set comdate [lindex $line end-1]
gitk: Allow unbalanced quotes/braces in commit headers When parsing commits, gitk treats the headers of the commit as tcl lists. This causes errors if the header contains an unbalanced quote or open brace. Splitting the line on spaces allows us to treat it as a set of words instead of as a tcl list, which prevents errors. Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-18 10:26:48 +01:00
set comname [join [lrange $line 1 end-2] " "]
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
}
}
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set headline {}
gitk: Cope with commit messages with carriage-returns and initial blank lines In some repositories imported from other systems we can get carriage return characters in the commit message, which leads to a multi-line headline being displayed in the summary window, which looks bad. Also some commit messages start with one or more blank lines, which leads to an empty headline. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 02:56:02 +02:00
# take the first non-blank line of the comment as the headline
set headline [string trimleft $comment]
set i [string first "\n" $headline]
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
if {$i >= 0} {
gitk: Cope with commit messages with carriage-returns and initial blank lines In some repositories imported from other systems we can get carriage return characters in the commit message, which leads to a multi-line headline being displayed in the summary window, which looks bad. Also some commit messages start with one or more blank lines, which leads to an empty headline. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 02:56:02 +02:00
set headline [string range $headline 0 $i]
}
set headline [string trimright $headline]
set i [string first "\r" $headline]
if {$i >= 0} {
set headline [string trimright [string range $headline 0 $i]]
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
}
if {!$listed} {
gitk: Correct a few strings and comments to say "git log" ... instead of "git rev-list", since we now use git log for generating the list of commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-04 11:14:17 +01:00
# git log indents the comment by 4 spaces;
[PATCH] gitk: Replace "git-" commands with "git " git-* commands work only if gitexecdir is in PATH. Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 09:57:40 +02:00
# if we got this via git cat-file, add the indentation
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set newcomment {}
foreach line [split $comment "\n"] {
append newcomment " "
append newcomment $line
gitk: Fix some bugs introduced by speedup changes Commits that weren't read from git-rev-list, i.e. the ones displayed with an open circle, were displayed incorrectly: the headline was null if there was only one line, and the commit comment was put all on one line. Also, the terminal commits weren't displayed when -r was used. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-20 13:08:22 +01:00
append newcomment "\n"
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
}
set comment $newcomment
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
}
if {$comdate != {}} {
Use git-rev-list instead of git-rev-tree. Fix bug in changing font size in entry widgets. Fix bug with B1 click before anything has been drawn. Use "units" and "pages" instead of "u" and "p" for tk8.5.
2005-05-31 14:14:42 +02:00
set cdate($id) $comdate
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
}
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
set commitinfo($id) [list $headline $auname $audate \
$comname $comdate $comment]
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
}
gitk: Make commitdata an array rather than a list This turns out to be slightly simpler and faster, and will make things a little easier when we do multiple view support. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 00:04:48 +01:00
proc getcommit {id} {
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
global commitdata commitinfo
gitk: Further speedups Now we don't parse the commits as we are reading them, we just put commit data on a list as a blob, and instead parse the commit when we need the various parts of it, such as when a commit is drawn on the canvas. This makes searching a bit more interesting: now we scan through the commit blobs doing a string or regexp match to find commits that might match, then for those that might match, we parse the commit info (if it isn't already parsed) and do the matching for the various fields as before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 12:56:44 +01:00
gitk: Make commitdata an array rather than a list This turns out to be slightly simpler and faster, and will make things a little easier when we do multiple view support. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 00:04:48 +01:00
if {[info exists commitdata($id)]} {
parsecommit $id $commitdata($id) 1
gitk: Further speedups Now we don't parse the commits as we are reading them, we just put commit data on a list as a blob, and instead parse the commit when we need the various parts of it, such as when a commit is drawn on the canvas. This makes searching a bit more interesting: now we scan through the commit blobs doing a string or regexp match to find commits that might match, then for those that might match, we parse the commit info (if it isn't already parsed) and do the matching for the various fields as before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 12:56:44 +01:00
} else {
readcommit $id
if {![info exists commitinfo($id)]} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
set commitinfo($id) [list [mc "No commit information available"]]
gitk: Further speedups Now we don't parse the commits as we are reading them, we just put commit data on a list as a blob, and instead parse the commit when we need the various parts of it, such as when a commit is drawn on the canvas. This makes searching a bit more interesting: now we scan through the commit blobs doing a string or regexp match to find commits that might match, then for those that might match, we parse the commit info (if it isn't already parsed) and do the matching for the various fields as before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 12:56:44 +01:00
}
}
return 1
}
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
# Expand an abbreviated commit ID to a list of full 40-char IDs that match
# and are present in the current view.
# This is fairly slow...
proc longid {prefix} {
global varcid curview
set ids {}
foreach match [array names varcid "$curview,$prefix*"] {
lappend ids [lindex [split $match ","] 1]
}
return $ids
}
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
proc readrefs {} {
gitk: Speed up the reading of references We were doing two execs for each tag - one to map the tag ID to a commit ID and one to read the contents of the tag for later display. This speeds up the process by not reading the contents of the tag (instead it is read later if needed), and by using the -d flag to git show-ref, which gives us refs/tags/foo^{} lines which give us the commit ID. Also this uses string operations instead of regexps. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-11 02:36:53 +02:00
global tagids idtags headids idheads tagobjid
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
global otherrefids idotherrefs mainhead mainheadid
gitk: Add option to specify the default commit on command line Other GUI tools may need to start gitk and make it automatically select a certain commit. This adds a new command-line option --select-commit=id to make that possible. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:27:44 +02:00
global selecthead selectheadid
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
global hideremotes
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
[PATCH] gitk: add Update menu item. Update will redraw the commits if any commits have been added to any of the selected heads. The new commits appear on the top. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 22:15:51 +01:00
foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
catch {unset $v}
}
gitk: Speed up the reading of references We were doing two execs for each tag - one to map the tag ID to a commit ID and one to read the contents of the tag for later display. This speeds up the process by not reading the contents of the tag (instead it is read later if needed), and by using the -d flag to git show-ref, which gives us refs/tags/foo^{} lines which give us the commit ID. Also this uses string operations instead of regexps. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-11 02:36:53 +02:00
set refd [open [list | git show-ref -d] r]
while {[gets $refd line] >= 0} {
if {[string index $line 40] ne " "} continue
set id [string range $line 0 39]
set ref [string range $line 41 end]
if {![string match "refs/*" $ref]} continue
set name [string range $ref 5 end]
if {[string match "remotes/*" $name]} {
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
if {![string match "*/HEAD" $name] && !$hideremotes} {
gitk: Speed up the reading of references We were doing two execs for each tag - one to map the tag ID to a commit ID and one to read the contents of the tag for later display. This speeds up the process by not reading the contents of the tag (instead it is read later if needed), and by using the -d flag to git show-ref, which gives us refs/tags/foo^{} lines which give us the commit ID. Also this uses string operations instead of regexps. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-11 02:36:53 +02:00
set headids($name) $id
lappend idheads($id) $name
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
}
gitk: Speed up the reading of references We were doing two execs for each tag - one to map the tag ID to a commit ID and one to read the contents of the tag for later display. This speeds up the process by not reading the contents of the tag (instead it is read later if needed), and by using the -d flag to git show-ref, which gives us refs/tags/foo^{} lines which give us the commit ID. Also this uses string operations instead of regexps. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-11 02:36:53 +02:00
} elseif {[string match "heads/*" $name]} {
set name [string range $name 6 end]
readrefs: grab all refs with one call to ls-remote. Instead of reading refs/heads/* and refs/tags/* files ourselves and missing files in subdirectories of heads/ and tags/, use ls-remote on local repository and grab all of them. This lets us also remove the procedure readotherrefs. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19 08:54:17 +01:00
set headids($name) $id
lappend idheads($id) $name
gitk: Speed up the reading of references We were doing two execs for each tag - one to map the tag ID to a commit ID and one to read the contents of the tag for later display. This speeds up the process by not reading the contents of the tag (instead it is read later if needed), and by using the -d flag to git show-ref, which gives us refs/tags/foo^{} lines which give us the commit ID. Also this uses string operations instead of regexps. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-11 02:36:53 +02:00
} elseif {[string match "tags/*" $name]} {
# this lets refs/tags/foo^{} overwrite refs/tags/foo,
# which is what we want since the former is the commit ID
set name [string range $name 5 end]
if {[string match "*^{}" $name]} {
set name [string range $name 0 end-3]
} else {
set tagobjid($name) $id
}
set tagids($name) $id
lappend idtags($id) $name
readrefs: grab all refs with one call to ls-remote. Instead of reading refs/heads/* and refs/tags/* files ourselves and missing files in subdirectories of heads/ and tags/, use ls-remote on local repository and grab all of them. This lets us also remove the procedure readotherrefs. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19 08:54:17 +01:00
} else {
set otherrefids($name) $id
lappend idotherrefs($id) $name
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
}
}
[PATCH] gitk: Continue and show error message in new repos If there is no commit made yet, gitk just dumps a Tcl error on stderr, which sometimes is hard to see. Noticed when gitk was run from Xfce file manager (thunar's custom action). Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-29 22:28:40 +02:00
catch {close $refd}
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
set mainhead {}
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set mainheadid {}
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
catch {
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
set mainheadid [exec git rev-parse HEAD]
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
set thehead [exec git symbolic-ref HEAD]
if {[string match "refs/heads/*" $thehead]} {
set mainhead [string range $thehead 11 end]
}
}
gitk: Add option to specify the default commit on command line Other GUI tools may need to start gitk and make it automatically select a certain commit. This adds a new command-line option --select-commit=id to make that possible. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:27:44 +02:00
set selectheadid {}
if {$selecthead ne {}} {
catch {
set selectheadid [exec git rev-parse --verify $selecthead]
}
}
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
}
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
# skip over fake commits
proc first_real_row {} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global nullid nullid2 numcommits
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
for {set row 0} {$row < $numcommits} {incr row} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set id [commitonrow $row]
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
if {$id ne $nullid && $id ne $nullid2} {
break
}
}
return $row
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
# update things for a head moved to a child of its previous location
proc movehead {id name} {
global headids idheads
removehead $headids($name) $name
set headids($name) $id
lappend idheads($id) $name
}
# update things when a head has been removed
proc removehead {id name} {
global headids idheads
if {$idheads($id) eq $name} {
unset idheads($id)
} else {
set i [lsearch -exact $idheads($id) $name]
if {$i >= 0} {
set idheads($id) [lreplace $idheads($id) $i $i]
}
}
unset headids($name)
}
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
proc make_transient {window origin} {
global have_tk85
# In MacOS Tk 8.4 transient appears to work by setting
# overrideredirect, which is utterly useless, since the
# windows get no border, and are not even kept above
# the parent.
if {!$have_tk85 && [tk windowingsystem] eq {aqua}} return
wm transient $window $origin
# Windows fails to place transient windows normally, so
# schedule a callback to center them on the parent.
if {[tk windowingsystem] eq {win32}} {
after idle [list tk::PlaceWindow $window widget $origin]
}
}
gitk: show_error fix Bug noted by Junio C Hamano: show_error can be passed "." (root window) as its $w argument, but appending ".m" and ".ok" results in creating "..m" and "..ok" as window paths, which were invalid. This fixes it in a slightly different way from Junio's patch, though. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 14:34:30 +02:00
proc show_error {w top msg} {
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $w.ok -text [mc OK] -command "destroy $top"
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
pack $w.ok -side bottom -fill x
gitk: show_error fix Bug noted by Junio C Hamano: show_error can be passed "." (root window) as its $w argument, but appending ".m" and ".ok" results in creating "..m" and "..ok" as window paths, which were invalid. This fixes it in a slightly different way from Junio's patch, though. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 14:34:30 +02:00
bind $top <Visibility> "grab $top; focus $top"
bind $top <Key-Return> "destroy $top"
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Key-space> "destroy $top"
bind $top <Key-Escape> "destroy $top"
gitk: show_error fix Bug noted by Junio C Hamano: show_error can be passed "." (root window) as its $w argument, but appending ".m" and ".ok" results in creating "..m" and "..ok" as window paths, which were invalid. This fixes it in a slightly different way from Junio's patch, though. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 14:34:30 +02:00
tkwait window $top
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
proc error_popup {msg {owner .}} {
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
set w .error
toplevel $w
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $w $owner
gitk: show_error fix Bug noted by Junio C Hamano: show_error can be passed "." (root window) as its $w argument, but appending ".m" and ".ok" results in creating "..m" and "..ok" as window paths, which were invalid. This fixes it in a slightly different way from Junio's patch, though. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 14:34:30 +02:00
show_error $w $w $msg
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
}
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
proc confirm_popup {msg {owner .}} {
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
global confirm_ok
set confirm_ok 0
set w .confirm
toplevel $w
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $w $owner
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $w.ok -text [mc OK] -command "set confirm_ok 1; destroy $w"
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
pack $w.ok -side left -fill x
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $w.cancel -text [mc Cancel] -command "destroy $w"
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
pack $w.cancel -side right -fill x
bind $w <Visibility> "grab $w; focus $w"
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $w <Key-Return> "set confirm_ok 1; destroy $w"
bind $w <Key-space> "set confirm_ok 1; destroy $w"
bind $w <Key-Escape> "destroy $w"
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
tkwait window $w
return $confirm_ok
}
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
proc setoptions {} {
option add *Panedwindow.showHandle 1 startupFile
option add *Panedwindow.sashRelief raised startupFile
option add *Button.font uifont startupFile
option add *Checkbutton.font uifont startupFile
option add *Radiobutton.font uifont startupFile
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
if {[tk windowingsystem] ne "aqua"} {
option add *Menu.font uifont startupFile
}
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
option add *Menubutton.font uifont startupFile
option add *Label.font uifont startupFile
option add *Message.font uifont startupFile
option add *Entry.font uifont startupFile
}
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
# Make a menu and submenus.
# m is the window name for the menu, items is the list of menu items to add.
# Each item is a list {mc label type description options...}
# mc is ignored; it's so we can put mc there to alert xgettext
# label is the string that appears in the menu
# type is cascade, command or radiobutton (should add checkbutton)
# description depends on type; it's the sublist for cascade, the
# command to invoke for command, or {variable value} for radiobutton
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
proc makemenu {m items} {
menu $m
gitk: Add accelerators to frequently used menu commands This commit documents keyboard accelerators used for menu commands in the menu, as it is usually done, and adds some more, e.g. F4 to invoke Edit View (or New View if the current view is the un-editable "All files" view). The changes include a workaround for handling Shift-F4 on systems where XKB binds special XF86_Switch_VT_* symbols to Ctrl-Alt-F* combinations. Tk often receives these codes when Shift-F* is pressed, so it is necessary to bind the relevant actions to them as well. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 11:00:45 +01:00
if {[tk windowingsystem] eq {aqua}} {
set Meta1 Cmd
} else {
set Meta1 Ctrl
}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
foreach i $items {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
set name [mc [lindex $i 1]]
set type [lindex $i 2]
set thing [lindex $i 3]
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
set params [list $type]
if {$name ne {}} {
set u [string first "&" [string map {&& x} $name]]
lappend params -label [string map {&& & & {}} $name]
if {$u >= 0} {
lappend params -underline $u
}
}
switch -- $type {
"cascade" {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
set submenu [string tolower [string map {& ""} [lindex $i 1]]]
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
lappend params -menu $m.$submenu
}
"command" {
lappend params -command $thing
}
"radiobutton" {
lappend params -variable [lindex $thing 0] \
-value [lindex $thing 1]
}
}
gitk: Add accelerators to frequently used menu commands This commit documents keyboard accelerators used for menu commands in the menu, as it is usually done, and adds some more, e.g. F4 to invoke Edit View (or New View if the current view is the un-editable "All files" view). The changes include a workaround for handling Shift-F4 on systems where XKB binds special XF86_Switch_VT_* symbols to Ctrl-Alt-F* combinations. Tk often receives these codes when Shift-F* is pressed, so it is necessary to bind the relevant actions to them as well. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 11:00:45 +01:00
set tail [lrange $i 4 end]
regsub -all {\yMeta1\y} $tail $Meta1 tail
eval $m add $params $tail
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
if {$type eq "cascade"} {
makemenu $m.$submenu $thing
}
}
}
# translate string and remove ampersands
proc mca {str} {
return [string map {&& & & {}} [mc $str]]
}
gitk: Make File->Update work properly again If a view is selected it will now just update that view. Also fixed a few other things - if you switch away from a view while gitk is still reading it in, then switch back, gitk will re-read it from scratch. We now re-read the references when switching views. If something was selected before a view change, and we need to read in the new view, we now select the previously-selected commit when we come across it. Fixed a bug in setting of rowrangelist plus a couple of other minor things. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-06 02:18:23 +02:00
proc makewindow {} {
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
global canv canv2 canv3 linespc charspc ctext cflist cscroll
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
global tabstop
Add "Files" and "Pickaxe" to the find menu. "Files" matches the find string against each of the files modified by each commit, and can do exact, case-ignoring or regexp matching. "Pickaxe" uses git-diff-tree -S'string' and can only do exact matching. I called it "pickaxe" rather than "find within patch" since it only finds commits where the string is present in the child but not the parents or vice versa, and "pickaxe" is what the author of that feature calls it.
2005-07-16 13:46:13 +02:00
global findtype findtypemenu findloc findstring fstring geometry
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
global entries sha1entry sha1string sha1but
[PATCH] gitk: Let user easily specify lines of context in diff view More lines of context sometimes help to better understand a diff. This patch introduces a text field above the box displaying the blobdiffs. You can type in the number of lines of context that you wish to view. The number of lines of context is saved to ~/.gitk. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 12:05:46 +02:00
global diffcontextstring diffcontext
[PATCH] gitk: Add checkbutton to ignore space changes Ignoring space changes can be helpful. For example, a commit claims to only reformat source code and you quickly want to verify if this claim is true. Or a commit accidentally changes code formatting and you want to focus on the real changes. In such cases a button to toggle of whitespace changes would be quite handy. You could quickly toggle between seeing and ignoring whitespace changes. This commit adds such a checkbutton right above the diff view. However, in general it is a good thing to see whitespace changes and therefore the state of the checkbutton is not saved. For example, space changes might happen unintentionally. But they are real changes yielding different sha1s for the blobs involved. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-17 23:42:55 +01:00
global ignorespace
Change cursor to a hand cursor when over a SHA1 ID link. This is based on suggestions by Jeff Epler and Linus Torvalds, but extended so that we do the switching between the watch cursor and the normal cursor correctly as well. Also fixed a bug pointed out by Junio Hamano - I wasn't incrementing the link number (duh!).
2005-08-07 07:27:57 +02:00
global maincursor textcursor curtextcursor
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
global rowctxmenu fakerowmenu mergemax wrapcomment
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
global highlight_files gdttype
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
global searchstring sstring
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
global bgcolor fgcolor bglist fglist diffcolors selectbgcolor
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
global headctxmenu progresscanv progressitem progresscoords statusw
global fprogitem fprogcoord lastprogupdate progupdatepending
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
global rprogitem rprogcoord rownumsel numcommits
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
global have_tk85
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
# The "mc" arguments here are purely so that xgettext
# sees the following string as needing to be translated
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
set file {
mc "File" cascade {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Update" command updatecommits -accelerator F5}
gitk: Add accelerators to frequently used menu commands This commit documents keyboard accelerators used for menu commands in the menu, as it is usually done, and adds some more, e.g. F4 to invoke Edit View (or New View if the current view is the un-editable "All files" view). The changes include a workaround for handling Shift-F4 on systems where XKB binds special XF86_Switch_VT_* symbols to Ctrl-Alt-F* combinations. Tk often receives these codes when Shift-F* is pressed, so it is necessary to bind the relevant actions to them as well. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 11:00:45 +01:00
{mc "Reload" command reloadcommits -accelerator Meta1-F5}
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Reread references" command rereadrefs}
gitk: Add accelerators to frequently used menu commands This commit documents keyboard accelerators used for menu commands in the menu, as it is usually done, and adds some more, e.g. F4 to invoke Edit View (or New View if the current view is the un-editable "All files" view). The changes include a workaround for handling Shift-F4 on systems where XKB binds special XF86_Switch_VT_* symbols to Ctrl-Alt-F* combinations. Tk often receives these codes when Shift-F* is pressed, so it is necessary to bind the relevant actions to them as well. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 11:00:45 +01:00
{mc "List references" command showrefs -accelerator F2}
gitk: Add a menu option to start git gui Git gui already has menu commands to start gitk, and this makes the relation symmetric. [paulus@samba.org - changed "Git Gui" in the menu item to "git gui"] Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 21:12:42 +01:00
{xx "" separator}
{mc "Start git gui" command {exec git gui &}}
{xx "" separator}
gitk: Add accelerators to frequently used menu commands This commit documents keyboard accelerators used for menu commands in the menu, as it is usually done, and adds some more, e.g. F4 to invoke Edit View (or New View if the current view is the un-editable "All files" view). The changes include a workaround for handling Shift-F4 on systems where XKB binds special XF86_Switch_VT_* symbols to Ctrl-Alt-F* combinations. Tk often receives these codes when Shift-F* is pressed, so it is necessary to bind the relevant actions to them as well. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 11:00:45 +01:00
{mc "Quit" command doquit -accelerator Meta1-Q}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
set edit {
mc "Edit" cascade {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Preferences" command doprefs}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
set view {
mc "View" cascade {
gitk: Add accelerators to frequently used menu commands This commit documents keyboard accelerators used for menu commands in the menu, as it is usually done, and adds some more, e.g. F4 to invoke Edit View (or New View if the current view is the un-editable "All files" view). The changes include a workaround for handling Shift-F4 on systems where XKB binds special XF86_Switch_VT_* symbols to Ctrl-Alt-F* combinations. Tk often receives these codes when Shift-F* is pressed, so it is necessary to bind the relevant actions to them as well. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 11:00:45 +01:00
{mc "New view..." command {newview 0} -accelerator Shift-F4}
{mc "Edit view..." command editview -state disabled -accelerator F4}
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Delete view" command delview -state disabled}
{xx "" separator}
{mc "All files" radiobutton {selectedview 0} -command {showview 0}}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
if {[tk windowingsystem] ne "aqua"} {
set help {
mc "Help" cascade {
{mc "About gitk" command about}
{mc "Key bindings" command keys}
}}
set bar [list $file $edit $view $help]
} else {
proc ::tk::mac::ShowPreferences {} {doprefs}
proc ::tk::mac::Quit {} {doquit}
lset file end [lreplace [lindex $file end] end-1 end]
set apple {
xx "Apple" cascade {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "About gitk" command about}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
{xx "" separator}
}}
set help {
mc "Help" cascade {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Key bindings" command keys}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
set bar [list $apple $file $view $help]
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
makemenu .bar $bar
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
. configure -menu .bar
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
# the gui has upper and lower half, parts of a paned window.
Use a panedwindow Make it cope with commits having parents that aren't listed.
2005-05-10 02:23:42 +02:00
panedwindow .ctop -orient vertical
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
# possibly use assumed geometry
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
if {![info exists geometry(pwsash0)]} {
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
set geometry(topheight) [expr {15 * $linespc}]
set geometry(topwidth) [expr {80 * $charspc}]
set geometry(botheight) [expr {15 * $linespc}]
set geometry(botwidth) [expr {50 * $charspc}]
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
set geometry(pwsash0) "[expr {40 * $charspc}] 2"
set geometry(pwsash1) "[expr {60 * $charspc}] 2"
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
}
# the upper half will have a paned window, a scroll bar to the right, and some stuff below
frame .tf -height $geometry(topheight) -width $geometry(topwidth)
frame .tf.histframe
panedwindow .tf.histframe.pwclist -orient horizontal -sashpad 0 -handlesize 4
# create three canvases
set cscroll .tf.histframe.csb
set canv .tf.histframe.pwclist.canv
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
canvas $canv \
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
-selectbackground $selectbgcolor \
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
-background $bgcolor -bd 0 \
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
-yscrollincr $linespc -yscrollcommand "scrollcanv $cscroll"
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.histframe.pwclist add $canv
set canv2 .tf.histframe.pwclist.canv2
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
canvas $canv2 \
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
-selectbackground $selectbgcolor \
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
-background $bgcolor -bd 0 -yscrollincr $linespc
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.histframe.pwclist add $canv2
set canv3 .tf.histframe.pwclist.canv3
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
canvas $canv3 \
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
-selectbackground $selectbgcolor \
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
-background $bgcolor -bd 0 -yscrollincr $linespc
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.histframe.pwclist add $canv3
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
eval .tf.histframe.pwclist sash place 0 $geometry(pwsash0)
eval .tf.histframe.pwclist sash place 1 $geometry(pwsash1)
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
# a scroll bar to rule them
scrollbar $cscroll -command {allcanvs yview} -highlightthickness 0
pack $cscroll -side right -fill y
bind .tf.histframe.pwclist <Configure> {resizeclistpanes %W %w}
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
lappend bglist $canv $canv2 $canv3
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
pack .tf.histframe.pwclist -fill both -expand 1 -side left
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
# we have two button bars at bottom of top frame. Bar 1
frame .tf.bar
frame .tf.lbar -height 15
set sha1entry .tf.bar.sha1
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
set entries $sha1entry
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
set sha1but .tf.bar.sha1label
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $sha1but -text [mc "SHA1 ID: "] -state disabled -relief flat \
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
-command gotocommit -width 8
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
$sha1but conf -disabledforeground [$sha1but cget -foreground]
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
pack .tf.bar.sha1label -side left
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
entry $sha1entry -width 40 -font textfont -textvariable sha1string
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
trace add variable sha1string write sha1change
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
pack $sha1entry -side left -pady 2
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
image create bitmap bm-left -data {
#define left_width 16
#define left_height 16
static unsigned char left_bits[] = {
0x00, 0x00, 0xc0, 0x01, 0xe0, 0x00, 0x70, 0x00, 0x38, 0x00, 0x1c, 0x00,
0x0e, 0x00, 0xff, 0x7f, 0xff, 0x7f, 0xff, 0x7f, 0x0e, 0x00, 0x1c, 0x00,
0x38, 0x00, 0x70, 0x00, 0xe0, 0x00, 0xc0, 0x01};
}
image create bitmap bm-right -data {
#define right_width 16
#define right_height 16
static unsigned char right_bits[] = {
0x00, 0x00, 0xc0, 0x01, 0x80, 0x03, 0x00, 0x07, 0x00, 0x0e, 0x00, 0x1c,
0x00, 0x38, 0xff, 0x7f, 0xff, 0x7f, 0xff, 0x7f, 0x00, 0x38, 0x00, 0x1c,
0x00, 0x0e, 0x00, 0x07, 0x80, 0x03, 0xc0, 0x01};
}
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
button .tf.bar.leftbut -image bm-left -command goback \
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
-state disabled -width 26
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
pack .tf.bar.leftbut -side left -fill y
button .tf.bar.rightbut -image bm-right -command goforw \
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
-state disabled -width 26
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
pack .tf.bar.rightbut -side left -fill y
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
label .tf.bar.rowlabel -text [mc "Row"]
set rownumsel {}
label .tf.bar.rownum -width 7 -font textfont -textvariable rownumsel \
-relief sunken -anchor e
label .tf.bar.rowlabel2 -text "/"
label .tf.bar.numcommits -width 7 -font textfont -textvariable numcommits \
-relief sunken -anchor e
pack .tf.bar.rowlabel .tf.bar.rownum .tf.bar.rowlabel2 .tf.bar.numcommits \
-side left
global selectedline
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
trace add variable selectedline write selectedline_change
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
# Status label and progress bar
set statusw .tf.bar.status
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
label $statusw -width 15 -relief sunken
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
pack $statusw -side left -padx 5
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set h [expr {[font metrics uifont -linespace] + 2}]
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
set progresscanv .tf.bar.progress
canvas $progresscanv -relief sunken -height $h -borderwidth 2
set progressitem [$progresscanv create rect -1 0 0 $h -fill green]
set fprogitem [$progresscanv create rect -1 0 0 $h -fill yellow]
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
set rprogitem [$progresscanv create rect -1 0 0 $h -fill red]
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
pack $progresscanv -side right -expand 1 -fill x
set progresscoords {0 0}
set fprogcoord 0
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
set rprogcoord 0
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
bind $progresscanv <Configure> adjustprogress
set lastprogupdate [clock clicks -milliseconds]
set progupdatepending 0
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
# build up the bottom bar of upper window
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
label .tf.lbar.flabel -text "[mc "Find"] "
button .tf.lbar.fnext -text [mc "next"] -command {dofind 1 1}
button .tf.lbar.fprev -text [mc "prev"] -command {dofind -1 1}
label .tf.lbar.flab2 -text " [mc "commit"] "
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
pack .tf.lbar.flabel .tf.lbar.fnext .tf.lbar.fprev .tf.lbar.flab2 \
-side left -fill y
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set gdttype [mc "containing:"]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
set gm [tk_optionMenu .tf.lbar.gdttype gdttype \
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
[mc "containing:"] \
[mc "touching paths:"] \
[mc "adding/removing string:"]]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
trace add variable gdttype write gdttype_change
pack .tf.lbar.gdttype -side left -fill y
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
set findstring {}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
set fstring .tf.lbar.findstring
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
lappend entries $fstring
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
entry $fstring -width 30 -font textfont -textvariable findstring
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
trace add variable findstring write find_change
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set findtype [mc "Exact"]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
set findtypemenu [tk_optionMenu .tf.lbar.findtype \
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
findtype [mc "Exact"] [mc "IgnCase"] [mc "Regexp"]]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
trace add variable findtype write findcom_change
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set findloc [mc "All fields"]
tk_optionMenu .tf.lbar.findloc findloc [mc "All fields"] [mc "Headline"] \
[mc "Comments"] [mc "Author"] [mc "Committer"]
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
trace add variable findloc write find_change
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
pack .tf.lbar.findloc -side right
pack .tf.lbar.findtype -side right
pack $fstring -side left -expand 1 -fill x
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
# Finish putting the upper half of the viewer together
pack .tf.lbar -in .tf -side bottom -fill x
pack .tf.bar -in .tf -side bottom -fill x
pack .tf.histframe -fill both -side top -expand 1
.ctop add .tf
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
.ctop paneconfigure .tf -height $geometry(topheight)
.ctop paneconfigure .tf -width $geometry(topwidth)
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
# now build up the bottom
panedwindow .pwbottom -orient horizontal
# lower left, a text box over search bar, scroll bar to the right
# if we know window height, then that will set the lower text height, otherwise
# we set lower text height which will drive window height
if {[info exists geometry(main)]} {
frame .bleft -width $geometry(botwidth)
} else {
frame .bleft -width $geometry(botwidth) -height $geometry(botheight)
}
frame .bleft.top
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
frame .bleft.mid
[PATCH] gitk: Add horizontal scrollbar to the diff view Adding horizontal scroll bar makes the scrolling feature more discoverable to the users. The horizontal scrollbar is a bit narrower than vertical ones so we don't make too big impact on available screen real estate. The text and scrollbar widget layout is done using grid geometry manager. An interesting side effect of Tk scrollbars is that the "elevator" size changes depending on the visible content. So the horizontal scrollbar "elevator" changes as the user scrolls the view up and down. Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-08 13:27:23 +01:00
frame .bleft.bottom
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
button .bleft.top.search -text [mc "Search"] -command dosearch
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
pack .bleft.top.search -side left -padx 5
set sstring .bleft.top.sstring
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
entry $sstring -width 20 -font textfont -textvariable searchstring
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
lappend entries $sstring
trace add variable searchstring write incrsearch
pack $sstring -side left -expand 1 -fill x
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
radiobutton .bleft.mid.diff -text [mc "Diff"] \
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
-command changediffdisp -variable diffelide -value {0 0}
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
radiobutton .bleft.mid.old -text [mc "Old version"] \
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
-command changediffdisp -variable diffelide -value {0 1}
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
radiobutton .bleft.mid.new -text [mc "New version"] \
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
-command changediffdisp -variable diffelide -value {1 0}
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
label .bleft.mid.labeldiffcontext -text " [mc "Lines of context"]: "
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
spinbox .bleft.mid.diffcontext -width 5 -font textfont \
gitk: Allow diff view without context lines Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-05-23 19:31:37 +02:00
-from 0 -increment 1 -to 10000000 \
[PATCH] gitk: Let user easily specify lines of context in diff view More lines of context sometimes help to better understand a diff. This patch introduces a text field above the box displaying the blobdiffs. You can type in the number of lines of context that you wish to view. The number of lines of context is saved to ~/.gitk. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 12:05:46 +02:00
-validate all -validatecommand "diffcontextvalidate %P" \
-textvariable diffcontextstring
.bleft.mid.diffcontext set $diffcontext
trace add variable diffcontextstring write diffcontextchange
lappend entries .bleft.mid.diffcontext
pack .bleft.mid.labeldiffcontext .bleft.mid.diffcontext -side left
[PATCH] gitk: Add checkbutton to ignore space changes Ignoring space changes can be helpful. For example, a commit claims to only reformat source code and you quickly want to verify if this claim is true. Or a commit accidentally changes code formatting and you want to focus on the real changes. In such cases a button to toggle of whitespace changes would be quite handy. You could quickly toggle between seeing and ignoring whitespace changes. This commit adds such a checkbutton right above the diff view. However, in general it is a good thing to see whitespace changes and therefore the state of the checkbutton is not saved. For example, space changes might happen unintentionally. But they are real changes yielding different sha1s for the blobs involved. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-17 23:42:55 +01:00
checkbutton .bleft.mid.ignspace -text [mc "Ignore space change"] \
-command changeignorespace -variable ignorespace
pack .bleft.mid.ignspace -side left -padx 5
[PATCH] gitk: Add horizontal scrollbar to the diff view Adding horizontal scroll bar makes the scrolling feature more discoverable to the users. The horizontal scrollbar is a bit narrower than vertical ones so we don't make too big impact on available screen real estate. The text and scrollbar widget layout is done using grid geometry manager. An interesting side effect of Tk scrollbars is that the "elevator" size changes depending on the visible content. So the horizontal scrollbar "elevator" changes as the user scrolls the view up and down. Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-08 13:27:23 +01:00
set ctext .bleft.bottom.ctext
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
text $ctext -background $bgcolor -foreground $fgcolor \
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
-state disabled -font textfont \
[PATCH] gitk: Add horizontal scrollbar to the diff view Adding horizontal scroll bar makes the scrolling feature more discoverable to the users. The horizontal scrollbar is a bit narrower than vertical ones so we don't make too big impact on available screen real estate. The text and scrollbar widget layout is done using grid geometry manager. An interesting side effect of Tk scrollbars is that the "elevator" size changes depending on the visible content. So the horizontal scrollbar "elevator" changes as the user scrolls the view up and down. Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-08 13:27:23 +01:00
-yscrollcommand scrolltext -wrap none \
-xscrollcommand ".bleft.bottom.sbhorizontal set"
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
if {$have_tk85} {
$ctext conf -tabstyle wordprocessor
}
[PATCH] gitk: Add horizontal scrollbar to the diff view Adding horizontal scroll bar makes the scrolling feature more discoverable to the users. The horizontal scrollbar is a bit narrower than vertical ones so we don't make too big impact on available screen real estate. The text and scrollbar widget layout is done using grid geometry manager. An interesting side effect of Tk scrollbars is that the "elevator" size changes depending on the visible content. So the horizontal scrollbar "elevator" changes as the user scrolls the view up and down. Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-08 13:27:23 +01:00
scrollbar .bleft.bottom.sb -command "$ctext yview"
scrollbar .bleft.bottom.sbhorizontal -command "$ctext xview" -orient h \
-width 10
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
pack .bleft.top -side top -fill x
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
pack .bleft.mid -side top -fill x
[PATCH] gitk: Add horizontal scrollbar to the diff view Adding horizontal scroll bar makes the scrolling feature more discoverable to the users. The horizontal scrollbar is a bit narrower than vertical ones so we don't make too big impact on available screen real estate. The text and scrollbar widget layout is done using grid geometry manager. An interesting side effect of Tk scrollbars is that the "elevator" size changes depending on the visible content. So the horizontal scrollbar "elevator" changes as the user scrolls the view up and down. Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-08 13:27:23 +01:00
grid $ctext .bleft.bottom.sb -sticky nsew
grid .bleft.bottom.sbhorizontal -sticky ew
grid columnconfigure .bleft.bottom 0 -weight 1
grid rowconfigure .bleft.bottom 0 -weight 1
grid rowconfigure .bleft.bottom 1 -weight 0
pack .bleft.bottom -side top -fill both -expand 1
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
lappend bglist $ctext
lappend fglist $ctext
Make getting file lists asynchronous Add some scrollbars
2005-05-11 02:45:38 +02:00
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
$ctext tag conf comment -wrap $wrapcomment
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
$ctext tag conf filesep -font textfontbold -back "#aaaaaa"
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
$ctext tag conf hunksep -fore [lindex $diffcolors 2]
$ctext tag conf d0 -fore [lindex $diffcolors 0]
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
$ctext tag conf dresult -fore [lindex $diffcolors 1]
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
$ctext tag conf m0 -fore red
$ctext tag conf m1 -fore blue
$ctext tag conf m2 -fore green
$ctext tag conf m3 -fore purple
$ctext tag conf m4 -fore brown
gitk: Use git-diff-tree --cc for showing the diffs for merges This replaces a lot of code that used the result from several 2-way diffs to generate a combined diff for a merge. Now we just use git-diff-tree --cc and colorize the output a bit, which is a lot simpler, and has the enormous advantage that if the diff doesn't show quite what someone thinks it should show, I can deflect the blame to someone else. :) Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:13:52 +01:00
$ctext tag conf m5 -fore "#009090"
$ctext tag conf m6 -fore magenta
$ctext tag conf m7 -fore "#808000"
$ctext tag conf m8 -fore "#009000"
$ctext tag conf m9 -fore "#ff0080"
$ctext tag conf m10 -fore cyan
$ctext tag conf m11 -fore "#b07070"
$ctext tag conf m12 -fore "#70b0f0"
$ctext tag conf m13 -fore "#70f0b0"
$ctext tag conf m14 -fore "#f0b070"
$ctext tag conf m15 -fore "#ff70b0"
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
$ctext tag conf mmax -fore darkgrey
gitk: Use git-diff-tree --cc for showing the diffs for merges This replaces a lot of code that used the result from several 2-way diffs to generate a combined diff for a merge. Now we just use git-diff-tree --cc and colorize the output a bit, which is a lot simpler, and has the enormous advantage that if the diff doesn't show quite what someone thinks it should show, I can deflect the blame to someone else. :) Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:13:52 +01:00
set mergemax 16
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
$ctext tag conf mresult -font textfontbold
$ctext tag conf msep -font textfontbold
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
$ctext tag conf found -back yellow
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.pwbottom add .bleft
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
.pwbottom paneconfigure .bleft -width $geometry(botwidth)
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
# lower right
frame .bright
frame .bright.mode
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
radiobutton .bright.mode.patch -text [mc "Patch"] \
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
-command reselectline -variable cmitmode -value "patch"
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
radiobutton .bright.mode.tree -text [mc "Tree"] \
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
-command reselectline -variable cmitmode -value "tree"
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
grid .bright.mode.patch .bright.mode.tree -sticky ew
pack .bright.mode -side top -fill x
set cflist .bright.cfiles
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set indent [font measure mainfont "nn"]
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
text $cflist \
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
-selectbackground $selectbgcolor \
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
-background $bgcolor -foreground $fgcolor \
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
-font mainfont \
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
-tabs [list $indent [expr {2 * $indent}]] \
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
-yscrollcommand ".bright.sb set" \
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
-cursor [. cget -cursor] \
-spacing1 1 -spacing3 1
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
lappend bglist $cflist
lappend fglist $cflist
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
scrollbar .bright.sb -command "$cflist yview"
pack .bright.sb -side right -fill y
Make getting file lists asynchronous Add some scrollbars
2005-05-11 02:45:38 +02:00
pack $cflist -side left -fill both -expand 1
gitk: Fix file list display when files are renamed The conversion of the file list to use a text widget assumed incorrectly that the list of files from git-diff-tree -r would correspond 1-1 with the diff sections in the output of git-diff-tree -r -p -C, which is not true when renames are detected. This fixes it by keeping the elements in the difffilestart list in the order they appear in the file list window. Since this means that the elements of difffilestart are no longer necessarily in ascending order, it's somewhat hard to do the dynamic highlighting in the file list as the diff window is scrolled, so I have taken that out for now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 11:55:31 +02:00
$cflist tag configure highlight \
-background [$cflist cget -selectbackground]
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
$cflist tag configure bold -font mainfontbold
Make getting file lists asynchronous Add some scrollbars
2005-05-11 02:45:38 +02:00
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.pwbottom add .bright
.ctop add .pwbottom
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
gitk: Only restore window size from ~/.gitk, not position This also limits the window size to the screen size. That is better than nothing, but it isn't perfect, since ideally we would take into account window decorations, and things such as gnome panels or the Mac OS X dock and menu bar, but I don't know how to do that. On Cygwin this is as good as restoring the whole geometry (size and position) at working around the Cygwin Tk bugs, according to Mark Levedahl. Tested-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-10 06:50:34 +01:00
# restore window width & height if known
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
if {[info exists geometry(main)]} {
gitk: Only restore window size from ~/.gitk, not position This also limits the window size to the screen size. That is better than nothing, but it isn't perfect, since ideally we would take into account window decorations, and things such as gnome panels or the Mac OS X dock and menu bar, but I don't know how to do that. On Cygwin this is as good as restoring the whole geometry (size and position) at working around the Cygwin Tk bugs, according to Mark Levedahl. Tested-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-10 06:50:34 +01:00
if {[scan $geometry(main) "%dx%d" w h] >= 2} {
if {$w > [winfo screenwidth .]} {
set w [winfo screenwidth .]
}
if {$h > [winfo screenheight .]} {
set h [winfo screenheight .]
}
wm geometry . "${w}x$h"
}
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
}
gitk: Remember and restore the window state with the geometry This records the window state in ~/.gitk. On startup, if the gitk window was previously maximized (zoomed), then we restore that state. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-14 23:09:53 +02:00
if {[info exists geometry(state)] && $geometry(state) eq "zoomed"} {
wm state . $geometry(state)
}
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS git-gui already uses the command key for accelerators, but gitk has never done so. I'm actually finding it very hard to move back and forth between the two applications as git-gui is following the Mac OS X conventions and gitk is not. This trick is the same one that git-gui uses to determine which key to bind actions to. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-19 06:37:58 +02:00
if {[tk windowingsystem] eq {aqua}} {
set M1B M1
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
set ::BM "3"
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS git-gui already uses the command key for accelerators, but gitk has never done so. I'm actually finding it very hard to move back and forth between the two applications as git-gui is following the Mac OS X conventions and gitk is not. This trick is the same one that git-gui uses to determine which key to bind actions to. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-19 06:37:58 +02:00
} else {
set M1B Control
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
set ::BM "2"
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS git-gui already uses the command key for accelerators, but gitk has never done so. I'm actually finding it very hard to move back and forth between the two applications as git-gui is following the Mac OS X conventions and gitk is not. This trick is the same one that git-gui uses to determine which key to bind actions to. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-19 06:37:58 +02:00
}
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
bind .pwbottom <Configure> {resizecdetpanes %W %w}
pack .ctop -fill both -expand 1
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
bindall <1> {selcanvline %W %x %y}
#bindall <B1-Motion> {selcanvline %W %x %y}
[PATCH] gitk: Handle MouseWheel events on Windows Windows, unlike X-Windows, sends mousewheel events by default to the window that has keyboard focus and uses the MouseWheel event to do so. The window to be scrolled must be able to take focus, but gitk's panels are disabled so cannot take focus. For all these reasons, a different design is needed to use the mousewheel on Windows. The approach here is to bind the mousewheel events to the top level window and redirect them based upon the current mouse position. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-08 03:40:35 +02:00
if {[tk windowingsystem] == "win32"} {
bind . <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D }
bind $ctext <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D ; break }
} else {
bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
gitk: Add support for OS X mouse wheel (Väinö Järvelä supplied this patch a while ago for 1.5.2. It no longer applied cleanly, so I'm reposting it.) MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all. So i added a support for the MouseWheel event, which i limited to Tcl/tk aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to be updated from the version that is shipped with OS X 10.4 Tiger, for this patch to work. Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15 11:33:07 +02:00
if {[tk windowingsystem] eq "aqua"} {
bindall <MouseWheel> {
set delta [expr {- (%D)}]
allcanvs yview scroll $delta units
}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
bindall <Shift-MouseWheel> {
set delta [expr {- (%D)}]
$canv xview scroll $delta units
}
gitk: Add support for OS X mouse wheel (Väinö Järvelä supplied this patch a while ago for 1.5.2. It no longer applied cleanly, so I'm reposting it.) MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all. So i added a support for the MouseWheel event, which i limited to Tcl/tk aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to be updated from the version that is shipped with OS X 10.4 Tiger, for this patch to work. Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15 11:33:07 +02:00
}
[PATCH] gitk: Handle MouseWheel events on Windows Windows, unlike X-Windows, sends mousewheel events by default to the window that has keyboard focus and uses the MouseWheel event to do so. The window to be scrolled must be able to take focus, but gitk's panels are disabled so cannot take focus. For all these reasons, a different design is needed to use the mousewheel on Windows. The approach here is to bind the mousewheel events to the top level window and redirect them based upon the current mouse position. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-08 03:40:35 +02:00
}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
bindall <$::BM> "canvscan mark %W %x %y"
bindall <B$::BM-Motion> "canvscan dragto %W %x %y"
[PATCH] gitk: add key bindings for selecting first and last commit For a keyboard addict like me some keys are still missing from gitk. Especially a key to select a commit when no commit is selected, like just after startup. While we're at it, complete the bindings for moving the view seperately from the selected line. Currently, the up and down keys act on the selected line while pageup and pagedown act on the commits viewed. The idea is to have to normal keys change the selected line: - Home selects first commit - End selects last commit - Up selects previous commit - Down selects next commit - PageUp moves selected line one page up - PageDown moves selected line one page down ...and together with the Control key, it moves the commits view: - Control-Home views first page of commits - Control-End views last page of commits - Control-Up moves commit view one line up - Control-Down moves commit view one line down - Control-PageUp moves commit view one page up - Control-PageDown moves commit view one page down Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl> and with some cleanups and simplifications... Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 02:24:03 +02:00
bindkey <Home> selfirstline
bindkey <End> sellastline
More fixes for geometry restoration Make up/down/pgup/pgdn work again Return in find string entry does find Scale circles and lines with font size Fix scrolling to make entire selected line visible Use white circle for commits not listed but put in to terminate lines Fix diff parsing for created and deleted files
2005-05-19 00:51:00 +02:00
bind . <Key-Up> "selnextline -1"
bind . <Key-Down> "selnextline 1"
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
bind . <Shift-Key-Up> "dofind -1 0"
bind . <Shift-Key-Down> "dofind 1 0"
[PATCH] gitk: add key bindings for selecting first and last commit For a keyboard addict like me some keys are still missing from gitk. Especially a key to select a commit when no commit is selected, like just after startup. While we're at it, complete the bindings for moving the view seperately from the selected line. Currently, the up and down keys act on the selected line while pageup and pagedown act on the commits viewed. The idea is to have to normal keys change the selected line: - Home selects first commit - End selects last commit - Up selects previous commit - Down selects next commit - PageUp moves selected line one page up - PageDown moves selected line one page down ...and together with the Control key, it moves the commits view: - Control-Home views first page of commits - Control-End views last page of commits - Control-Up moves commit view one line up - Control-Down moves commit view one line down - Control-PageUp moves commit view one page up - Control-PageDown moves commit view one page down Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl> and with some cleanups and simplifications... Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 02:24:03 +02:00
bindkey <Key-Right> "goforw"
bindkey <Key-Left> "goback"
bind . <Key-Prior> "selnextpage -1"
bind . <Key-Next> "selnextpage 1"
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS git-gui already uses the command key for accelerators, but gitk has never done so. I'm actually finding it very hard to move back and forth between the two applications as git-gui is following the Mac OS X conventions and gitk is not. This trick is the same one that git-gui uses to determine which key to bind actions to. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-19 06:37:58 +02:00
bind . <$M1B-Home> "allcanvs yview moveto 0.0"
bind . <$M1B-End> "allcanvs yview moveto 1.0"
bind . <$M1B-Key-Up> "allcanvs yview scroll -1 units"
bind . <$M1B-Key-Down> "allcanvs yview scroll 1 units"
bind . <$M1B-Key-Prior> "allcanvs yview scroll -1 pages"
bind . <$M1B-Key-Next> "allcanvs yview scroll 1 pages"
Use git-rev-list instead of git-rev-tree. Fix bug in changing font size in entry widgets. Fix bug with B1 click before anything has been drawn. Use "units" and "pages" instead of "u" and "p" for tk8.5.
2005-05-31 14:14:42 +02:00
bindkey <Key-Delete> "$ctext yview scroll -1 pages"
bindkey <Key-BackSpace> "$ctext yview scroll -1 pages"
bindkey <Key-space> "$ctext yview scroll 1 pages"
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
bindkey p "selnextline -1"
bindkey n "selnextline 1"
[PATCH] Add new keybindings This adds several new keybindings to allow history and selectline navigation. I basically added Opera-like history traversal, as well as left-right-cursor history traversal and vi-like motion commands. Signed-off-by: Robert Suetterlin <robert@mpe.mpg.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-09-22 02:07:36 +02:00
bindkey z "goback"
bindkey x "goforw"
bindkey i "selnextline -1"
bindkey k "selnextline 1"
bindkey j "goback"
bindkey l "goforw"
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
bindkey b prevfile
Use git-rev-list instead of git-rev-tree. Fix bug in changing font size in entry widgets. Fix bug with B1 click before anything has been drawn. Use "units" and "pages" instead of "u" and "p" for tk8.5.
2005-05-31 14:14:42 +02:00
bindkey d "$ctext yview scroll 18 units"
bindkey u "$ctext yview scroll -18 units"
gitk: Map / to focus the search box The / key is often used to initiate searches (less, vim, some web browsers). This changes the binding for the / (slash) key from 'find next' to 'focus the search box' to follow this convention. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-02 02:19:22 +01:00
bindkey / {focus $fstring}
gitk: Map KP_Divide to focus the search box Commit 97bed034 changed the behavior of the '/' key on the keyboard, but the '/' on the keypad was left unused. They now both do the same thing. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-30 14:55:21 +02:00
bindkey <Key-KP_Divide> {focus $fstring}
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
Accommodate new git-diff-tree output format Add 'f' key for moving to next file
2005-05-19 14:35:53 +02:00
bindkey f nextfile
gitk: Add accelerators to frequently used menu commands This commit documents keyboard accelerators used for menu commands in the menu, as it is usually done, and adds some more, e.g. F4 to invoke Edit View (or New View if the current view is the un-editable "All files" view). The changes include a workaround for handling Shift-F4 on systems where XKB binds special XF86_Switch_VT_* symbols to Ctrl-Alt-F* combinations. Tk often receives these codes when Shift-F* is pressed, so it is necessary to bind the relevant actions to them as well. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 11:00:45 +01:00
bind . <F5> updatecommits
bind . <$M1B-F5> reloadcommits
bind . <F2> showrefs
bind . <Shift-F4> {newview 0}
catch { bind . <Shift-Key-XF86_Switch_VT_4> {newview 0} }
bind . <F4> edit_or_newview
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS git-gui already uses the command key for accelerators, but gitk has never done so. I'm actually finding it very hard to move back and forth between the two applications as git-gui is following the Mac OS X conventions and gitk is not. This trick is the same one that git-gui uses to determine which key to bind actions to. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-19 06:37:58 +02:00
bind . <$M1B-q> doquit
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
bind . <$M1B-f> {dofind 1 1}
bind . <$M1B-g> {dofind 1 0}
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS git-gui already uses the command key for accelerators, but gitk has never done so. I'm actually finding it very hard to move back and forth between the two applications as git-gui is following the Mac OS X conventions and gitk is not. This trick is the same one that git-gui uses to determine which key to bind actions to. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-19 06:37:58 +02:00
bind . <$M1B-r> dosearchback
bind . <$M1B-s> dosearch
bind . <$M1B-equal> {incrfont 1}
[PATCH] gitk: make Ctrl "+" really increase the font size Only Ctrl "=" was bound to increase the font size, probably because English keyboards have the plus on the same key as the equal sign. However, not the whole world is English, and at least with some other keyboard layouts, Ctrl "+" did not work as documented. Noticed by Stephan Hennig. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-11 13:39:33 +01:00
bind . <$M1B-plus> {incrfont 1}
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS git-gui already uses the command key for accelerators, but gitk has never done so. I'm actually finding it very hard to move back and forth between the two applications as git-gui is following the Mac OS X conventions and gitk is not. This trick is the same one that git-gui uses to determine which key to bind actions to. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-19 06:37:58 +02:00
bind . <$M1B-KP_Add> {incrfont 1}
bind . <$M1B-minus> {incrfont -1}
bind . <$M1B-KP_Subtract> {incrfont -1}
Make gitk save and restore the user set window position. gitk was saving widget sizes and positions when the main window was destroyed, which is after all child widgets are destroyed. The cure is to trap the WM_DELETE_WINDOW event before the gui is torn down. Also, the saved geometry was captured using "winfo geometry .", rather than "wm geometry ." Under Linux, these two return different answers and the latter one is correct. [jc: credit goes to Brett Schwarz for suggesting the use of "wm protocol"; I also squashed the follow-up patch to remove extraneous -0 from expressions.] Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-09 04:22:24 +01:00
wm protocol . WM_DELETE_WINDOW doquit
gitk: Kill back-end processes on window close When collecting commits for a rarely changed, or recently created file or directory, rev-list may work for a noticeable period of time without producing any output. Such processes don't receive SIGPIPE for a while after gitk is closed, thus becoming runaway CPU hogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-12 14:09:28 +02:00
bind . <Destroy> {stop_backends}
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
bind . <Button-1> "click %W"
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
bind $fstring <Key-Return> {dofind 1 1}
gitk: Fix binding for <Return> in sha1 entry field This adds a break so that gitk doesn't go and execute the global binding for <Return> (i.e. find next) when the user presses the return key in the sha1 entry field to indicate that gitk should jump to the commit identified by what they just put into the sha1 field. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-16 00:57:02 +02:00
bind $sha1entry <Key-Return> {gotocommit; break}
Clear the SHA1 entry field when we go to paste something into it If the user pastes in the selection (with the middle mouse button) and it already has 40 characters in it, clear it before pasting.
2005-06-25 08:37:13 +02:00
bind $sha1entry <<PasteSelection>> clearsha1
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
bind $cflist <1> {sel_flist %W %x %y; break}
bind $cflist <B1-Motion> {sel_flist %W %x %y; break}
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
bind $cflist <ButtonRelease-1> {treeclick %W %x %y}
gitk: Use <Button-2> for context menus on OSX An OSX user has reported that gitk's context menus are not usable under OSX because it doesn't provide a way to generate <Button-3> events. Users can generate <Button-2> events with command+click, so use that for the context menus instead on OSX. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-22 01:11:37 +02:00
global ctxbut
bind $cflist $ctxbut {pop_flist_menu %W %X %Y %x %y}
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
bind $ctext $ctxbut {pop_diff_menu %W %X %Y %x %y}
Fix operation without libreadobj.so.0.0 Display a watch cursor when reading the commits initially
2005-06-16 12:54:04 +02:00
set maincursor [. cget -cursor]
set textcursor [$ctext cget -cursor]
Change cursor to a hand cursor when over a SHA1 ID link. This is based on suggestions by Jeff Epler and Linus Torvalds, but extended so that we do the switching between the watch cursor and the normal cursor correctly as well. Also fixed a bug pointed out by Junio Hamano - I wasn't incrementing the link number (duh!).
2005-08-07 07:27:57 +02:00
set curtextcursor $textcursor
Draw graph lines as one continuous line where possible Added context menu on lines Added headline display when the mouse hovers over a line Removed some debug messages
2005-06-17 02:12:26 +02:00
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
set rowctxmenu .rowctxmenu
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
makemenu $rowctxmenu {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Diff this -> selected" command {diffvssel 0}}
{mc "Diff selected -> this" command {diffvssel 1}}
{mc "Make patch" command mkpatch}
{mc "Create tag" command mktag}
{mc "Write commit to file" command writecommit}
{mc "Create new branch" command mkbranch}
{mc "Cherry-pick this commit" command cherrypick}
{mc "Reset HEAD branch to here" command resethead}
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
{mc "Mark this commit" command markhere}
{mc "Return to mark" command gotomark}
{mc "Find descendant of this and mark" command find_common_desc}
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
{mc "Compare with marked commit" command compare_commits}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}
$rowctxmenu configure -tearoff 0
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set fakerowmenu .fakerowmenu
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
makemenu $fakerowmenu {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Diff this -> selected" command {diffvssel 0}}
{mc "Diff selected -> this" command {diffvssel 1}}
{mc "Make patch" command mkpatch}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}
$fakerowmenu configure -tearoff 0
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
set headctxmenu .headctxmenu
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
makemenu $headctxmenu {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Check out this branch" command cobranch}
{mc "Remove this branch" command rmbranch}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}
$headctxmenu configure -tearoff 0
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
global flist_menu
set flist_menu .flistctxmenu
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
makemenu $flist_menu {
gitk: Regenerate .po files This is the result of running make update-po and removing or fixing the strings that were fuzzily matched. The ones that were fixed were the ones where the only change was "git rev-list" to "git log", and the "about gitk" message where the copyright year got updated. To get xgettext to see the menu labels as needing translation, it was necessary for arrange for them to be preceded by "mc". This therefore changes makemenu to ignore the first element in each menu item so that it can be "mc" in the makemenu call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-18 07:24:46 +02:00
{mc "Highlight this too" command {flist_hl 0}}
{mc "Highlight this only" command {flist_hl 1}}
{mc "External diff" command {external_diff}}
{mc "Blame parent commit" command {external_blame 1}}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
}
$flist_menu configure -tearoff 0
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
global diff_menu
set diff_menu .diffctxmenu
makemenu $diff_menu {
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
{mc "Show origin of this line" command show_line_source}
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
{mc "Run git gui blame on this line" command {external_blame_diff}}
}
$diff_menu configure -tearoff 0
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
[PATCH] gitk: Handle MouseWheel events on Windows Windows, unlike X-Windows, sends mousewheel events by default to the window that has keyboard focus and uses the MouseWheel event to do so. The window to be scrolled must be able to take focus, but gitk's panels are disabled so cannot take focus. For all these reasons, a different design is needed to use the mousewheel on Windows. The approach here is to bind the mousewheel events to the top level window and redirect them based upon the current mouse position. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-08 03:40:35 +02:00
# Windows sends all mouse wheel events to the current focused window, not
# the one where the mouse hovers, so bind those events here and redirect
# to the correct window
proc windows_mousewheel_redirector {W X Y D} {
global canv canv2 canv3
set w [winfo containing -displayof $W $X $Y]
if {$w ne ""} {
set u [expr {$D < 0 ? 5 : -5}]
if {$w == $canv || $w == $canv2 || $w == $canv3} {
allcanvs yview scroll $u units
} else {
catch {
$w yview scroll $u units
}
}
}
}
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
# Update row number label when selectedline changes
proc selectedline_change {n1 n2 op} {
global selectedline rownumsel
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {}} {
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
set rownumsel {}
} else {
set rownumsel [expr {$selectedline + 1}]
}
}
gitk: Allow top panes to scroll horizontally with mouse button 2 Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 00:55:11 +02:00
# mouse-2 makes all windows scan vertically, but only the one
# the cursor is in scans horizontally
proc canvscan {op w x y} {
global canv canv2 canv3
foreach c [list $canv $canv2 $canv3] {
if {$c == $w} {
$c scan $op $x $y
} else {
$c scan $op 0 $y
}
}
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
proc scrollcanv {cscroll f0 f1} {
$cscroll set $f0 $f1
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
drawvisible
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
flushhighlights
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
# when we make a key binding for the toplevel, make sure
# it doesn't get triggered when that key is pressed in the
# find string entry widget.
proc bindkey {ev script} {
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
global entries
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
bind . $ev $script
set escript [bind Entry $ev]
if {$escript == {}} {
set escript [bind Entry <Key>]
}
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
foreach e $entries {
bind $e $ev "$escript; break"
}
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
# set the focus back to the toplevel for any click outside
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
# the entry widgets
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
proc click {w} {
[PATCH] gitk: Enable selected patch text on Windows On windows, mouse input follows the keyboard focus, so to allow selecting text from the patch canvas we must not shift focus back to the top level. This change has no negative impact on X, so we don't explicitly test for Win32 on this change. This provides similar selection capability as already available using X-Windows. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-08 03:40:34 +02:00
global ctext entries
foreach e [concat $entries $ctext] {
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
if {$w == $e} return
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
focus .
save window geometry on exit, and restore it on startup
2005-05-17 01:54:58 +02:00
}
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
# Adjust the progress bar for a change in requested extent or canvas size
proc adjustprogress {} {
global progresscanv progressitem progresscoords
global fprogitem fprogcoord lastprogupdate progupdatepending
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
global rprogitem rprogcoord
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
set w [expr {[winfo width $progresscanv] - 4}]
set x0 [expr {$w * [lindex $progresscoords 0]}]
set x1 [expr {$w * [lindex $progresscoords 1]}]
set h [winfo height $progresscanv]
$progresscanv coords $progressitem $x0 0 $x1 $h
$progresscanv coords $fprogitem 0 0 [expr {$w * $fprogcoord}] $h
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
$progresscanv coords $rprogitem 0 0 [expr {$w * $rprogcoord}] $h
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
set now [clock clicks -milliseconds]
if {$now >= $lastprogupdate + 100} {
set progupdatepending 0
update
} elseif {!$progupdatepending} {
set progupdatepending 1
after [expr {$lastprogupdate + 100 - $now}] doprogupdate
}
}
proc doprogupdate {} {
global lastprogupdate progupdatepending
if {$progupdatepending} {
set progupdatepending 0
set lastprogupdate [clock clicks -milliseconds]
update
}
}
save window geometry on exit, and restore it on startup
2005-05-17 01:54:58 +02:00
proc savestuff {w} {
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
global canv canv2 canv3 mainfont textfont uifont tabstop
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
global stuffsaved findmergefiles maxgraphpct
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
global maxwidth showneartags showlocalchanges
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
global cmitmode wrapcomment datetimeformat limitdiffs
[PATCH] gitk: Let user easily specify lines of context in diff view More lines of context sometimes help to better understand a diff. This patch introduces a text field above the box displaying the blobdiffs. You can type in the number of lines of context that you wish to view. The number of lines of context is saved to ~/.gitk. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 12:05:46 +02:00
global colors bgcolor fgcolor diffcolors diffcontext selectbgcolor
gitk: Make the background color of marked lines configurable This makes it possible for the user to configure the background color of lines that are "marked". At the moment only the "show the origin of this line" function marks lines. This also makes the user's choice persistent by saving it in ~/.gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 12:37:21 +01:00
global autoselect extdifftool perfile_attrs markbgcolor
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
global hideremotes
Import the --topo-order change and fix the writing of ~/.gitk.
2005-07-28 05:16:51 +02:00
save window geometry on exit, and restore it on startup
2005-05-17 01:54:58 +02:00
if {$stuffsaved} return
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
if {![winfo viewable .]} return
save window geometry on exit, and restore it on startup
2005-05-17 01:54:58 +02:00
catch {
gitk: Work around leftover temporary save file If a file exists and is hidden on Windows the Tcl open command will fail as the attributes provided in the CREAT call fail to match those of the existing file. Forcing removal of the temporary file before we begin solves any problems caused by previous failures to save the application settings. An alternative would be to remove the hidden attribute before calling 'open'. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-15 11:26:30 +02:00
if {[file exists ~/.gitk-new]} {file delete -force ~/.gitk-new}
save window geometry on exit, and restore it on startup
2005-05-17 01:54:58 +02:00
set f [open "~/.gitk-new" w]
gitk: Make .gitk a hidden file under windows This sets the hidden attribute on the ~/.gitk file so it doesn't appear in the windows user profile. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 11:37:51 +01:00
if {$::tcl_platform(platform) eq {windows}} {
file attributes "~/.gitk-new" -hidden true
}
Make the diff display less gaudy. The old style is still available as an option (we still need a preferences window so we can set/clear it though).
2005-07-18 20:29:03 +02:00
puts $f [list set mainfont $mainfont]
puts $f [list set textfont $textfont]
[PATCH] Provide configurable UI font for gitk This makes the font used in the UI elements of gitk configurable in the same way the other fonts are. The default fonts used in the Xft build of tk8.5 are particularily horrific, making this change more important there. Signed-off-by: Keith Packard <keithp@neko.keithp.com> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 09:19:45 +02:00
puts $f [list set uifont $uifont]
[PATCH] gitk: Allow specifying tabstop as other than default 8 characters. Not all projects use the convention that one tabstop = 8 characters, and a common convention is to use one tabstop = one level of indent. For such projects, using 8 characters per tabstop often shows too much whitespace per indent. This allows the user to configure the number of characters to use per tabstop. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 17:45:50 +02:00
puts $f [list set tabstop $tabstop]
Make the diff display less gaudy. The old style is still available as an option (we still need a preferences window so we can set/clear it though).
2005-07-18 20:29:03 +02:00
puts $f [list set findmergefiles $findmergefiles]
Compress the graph horizontally if it gets too wide. If the graph gets to use more than a certain percentage (default 50%) of the width of the top-left pane, we now reduce the amount of space allowed for each graph line. This means it doesn't look quite as nice but you can still see the headline for the commit. (Currently the only way to customize the percentage is to edit your ~/.gitk file manually.)
2005-08-05 01:52:16 +02:00
puts $f [list set maxgraphpct $maxgraphpct]
Save the maxwidth setting in the ~/.gitk file.
2005-08-19 02:22:24 +02:00
puts $f [list set maxwidth $maxwidth]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
puts $f [list set cmitmode $cmitmode]
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
puts $f [list set wrapcomment $wrapcomment]
[PATCH] gitk: make autoselect optional Whenever a commit is selected in the graph pane, its SHA1 is automatically put into the selection buffer for cut and paste. However, some users may find this behavior annoying since it can overwrite something they actually wanted to keep in the buffer. This makes the behavior optional under the name "Auto-select SHA1", but continues to default to "on". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-06 12:49:25 +01:00
puts $f [list set autoselect $autoselect]
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
puts $f [list set showneartags $showneartags]
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
puts $f [list set hideremotes $hideremotes]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
puts $f [list set showlocalchanges $showlocalchanges]
[PATCH] gitk: Make the date/time display configurable The new 'datetimeformat' configuration variable in ~/.gitk can be set to a Tcl 'clock format' format string to modify the display of dates and times. http://www.tcl.tk/man/tcl8.4/TclCmd/clock.htm has a list of allowed fields. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-14 22:02:04 +02:00
puts $f [list set datetimeformat $datetimeformat]
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
puts $f [list set limitdiffs $limitdiffs]
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
puts $f [list set bgcolor $bgcolor]
puts $f [list set fgcolor $fgcolor]
puts $f [list set colors $colors]
puts $f [list set diffcolors $diffcolors]
gitk: Make the background color of marked lines configurable This makes it possible for the user to configure the background color of lines that are "marked". At the moment only the "show the origin of this line" function marks lines. This also makes the user's choice persistent by saving it in ~/.gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 12:37:21 +01:00
puts $f [list set markbgcolor $markbgcolor]
[PATCH] gitk: Let user easily specify lines of context in diff view More lines of context sometimes help to better understand a diff. This patch introduces a text field above the box displaying the blobdiffs. You can type in the number of lines of context that you wish to view. The number of lines of context is saved to ~/.gitk. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 12:05:46 +02:00
puts $f [list set diffcontext $diffcontext]
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
puts $f [list set selectbgcolor $selectbgcolor]
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
puts $f [list set extdifftool $extdifftool]
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
puts $f [list set perfile_attrs $perfile_attrs]
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
Make gitk save and restore the user set window position. gitk was saving widget sizes and positions when the main window was destroyed, which is after all child widgets are destroyed. The cure is to trap the WM_DELETE_WINDOW event before the gui is torn down. Also, the saved geometry was captured using "winfo geometry .", rather than "wm geometry ." Under Linux, these two return different answers and the latter one is correct. [jc: credit goes to Brett Schwarz for suggesting the use of "wm protocol"; I also squashed the follow-up patch to remove extraneous -0 from expressions.] Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-09 04:22:24 +01:00
puts $f "set geometry(main) [wm geometry .]"
gitk: Remember and restore the window state with the geometry This records the window state in ~/.gitk. On startup, if the gitk window was previously maximized (zoomed), then we restore that state. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-14 23:09:53 +02:00
puts $f "set geometry(state) [wm state .]"
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
puts $f "set geometry(topwidth) [winfo width .tf]"
puts $f "set geometry(topheight) [winfo height .tf]"
Make gitk save and restore window pane position on Linux and Cygwin. Subtle bugs remained on both Cygwin and Linux that caused the various window panes to be restored in positions different than where the user last placed them. Sergey Vlasov posed a pair of suggested fixes to this, what is done here is slightly different. The basic fix here involves a) explicitly remembering and restoring the sash positions for the upper window, and b) using paneconfigure to redundantly set height and width of other elements. This redundancy is needed as Cygwin Tcl has a nasty habit of setting pane sizes to zero if their slaves are not configured with a specific size, but Linux Tcl does not honor the specific size given. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-13 01:19:34 +01:00
puts $f "set geometry(pwsash0) \"[.tf.histframe.pwclist sash coord 0]\""
puts $f "set geometry(pwsash1) \"[.tf.histframe.pwclist sash coord 1]\""
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
puts $f "set geometry(botwidth) [winfo width .bleft]"
puts $f "set geometry(botheight) [winfo height .bleft]"
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
puts -nonewline $f "set permviews {"
for {set v 0} {$v < $nextviewnum} {incr v} {
if {$viewperm($v)} {
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v) $viewargscmd($v)]}"
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
}
}
puts $f "}"
save window geometry on exit, and restore it on startup
2005-05-17 01:54:58 +02:00
close $f
file rename -force "~/.gitk-new" "~/.gitk"
}
set stuffsaved 1
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
}
Resize the panes in the paned windows (commit list and details) to keep the proportionality of the pane widths as the overall window is resized.
2005-05-16 01:19:18 +02:00
proc resizeclistpanes {win w} {
global oldwidth
gitk: Add braces around if expressions Apparently this simplifies things for the parser/compiler and makes it go slightly faster (since without the braces, it potentially has to do two levels of substitutions rather than one). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:10:18 +01:00
if {[info exists oldwidth($win)]} {
Resize the panes in the paned windows (commit list and details) to keep the proportionality of the pane widths as the overall window is resized.
2005-05-16 01:19:18 +02:00
set s0 [$win sash coord 0]
set s1 [$win sash coord 1]
if {$w < 60} {
set sash0 [expr {int($w/2 - 2)}]
set sash1 [expr {int($w*5/6 - 2)}]
} else {
set factor [expr {1.0 * $w / $oldwidth($win)}]
set sash0 [expr {int($factor * [lindex $s0 0])}]
set sash1 [expr {int($factor * [lindex $s1 0])}]
if {$sash0 < 30} {
set sash0 30
}
if {$sash1 < $sash0 + 20} {
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set sash1 [expr {$sash0 + 20}]
Resize the panes in the paned windows (commit list and details) to keep the proportionality of the pane widths as the overall window is resized.
2005-05-16 01:19:18 +02:00
}
if {$sash1 > $w - 10} {
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set sash1 [expr {$w - 10}]
Resize the panes in the paned windows (commit list and details) to keep the proportionality of the pane widths as the overall window is resized.
2005-05-16 01:19:18 +02:00
if {$sash0 > $sash1 - 20} {
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set sash0 [expr {$sash1 - 20}]
Resize the panes in the paned windows (commit list and details) to keep the proportionality of the pane widths as the overall window is resized.
2005-05-16 01:19:18 +02:00
}
}
}
$win sash place 0 $sash0 [lindex $s0 1]
$win sash place 1 $sash1 [lindex $s1 1]
}
set oldwidth($win) $w
}
proc resizecdetpanes {win w} {
global oldwidth
gitk: Add braces around if expressions Apparently this simplifies things for the parser/compiler and makes it go slightly faster (since without the braces, it potentially has to do two levels of substitutions rather than one). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:10:18 +01:00
if {[info exists oldwidth($win)]} {
Resize the panes in the paned windows (commit list and details) to keep the proportionality of the pane widths as the overall window is resized.
2005-05-16 01:19:18 +02:00
set s0 [$win sash coord 0]
if {$w < 60} {
set sash0 [expr {int($w*3/4 - 2)}]
} else {
set factor [expr {1.0 * $w / $oldwidth($win)}]
set sash0 [expr {int($factor * [lindex $s0 0])}]
if {$sash0 < 45} {
set sash0 45
}
if {$sash0 > $w - 15} {
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set sash0 [expr {$w - 15}]
Resize the panes in the paned windows (commit list and details) to keep the proportionality of the pane widths as the overall window is resized.
2005-05-16 01:19:18 +02:00
}
}
$win sash place 0 $sash0 [lindex $s0 1]
}
set oldwidth($win) $w
}
source ~/.gitk for user-specific option settings use a panedwindow for the main list with three panes, and make them scroll together
2005-05-10 14:08:22 +02:00
proc allcanvs args {
global canv canv2 canv3
eval $canv $args
eval $canv2 $args
eval $canv3 $args
}
proc bindall {event action} {
global canv canv2 canv3
bind $canv $event $action
bind $canv2 $event $action
bind $canv3 $event $action
}
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
proc about {} {
[PATCH] Teach gitk to use the user-defined UI font everywhere. Some parts of gitk were not respecting the default GUI font. Most of them were catched and fixed. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-27 12:36:12 +02:00
global uifont
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
set w .about
if {[winfo exists $w]} {
raise $w
return
}
toplevel $w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
wm title $w [mc "About gitk"]
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $w .
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
message $w.m -text [mc "
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
Gitk - a commit viewer for git
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
gitk: Make updates go faster This goes back to the method of doing updates where we translate the revisions we're given to SHA1 ids and then remove the ones we've asked for before or that we've already come across. This speeds up updates enormously in most cases since it means git log doesn't have to traverse large parts of the tree. We used to do this, but it had bugs, and commit 468bcaedbb1589f16955e63b6bfba01c2f53e433 (gitk: Don't filter view arguments through git rev-parse) went to the slower method to avoid the bugs. In order to do this properly, we have to parse the command line and understand all the flag arguments. So this adds a parser that checks all the flag arguments. If there are any we don't know about, we disable the optimization and just pass the whole lot to git log (except for -d/--date-order, which we remove from the list). With this we can then use git rev-parse on the non-flag arguments to work out exactly what SHA1 ids are included and excluded in the list, which then enables us to ask for just the new ones when updating. One wrinkle is that we have to turn symmetric diff arguments (of the form a...b) back into symmetric diff form so that --left-right still works, as git rev parse turns a...b into a b ^merge_base(a,b). This also updates a couple of copyright notices. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-09 02:14:07 +02:00
Copyright © 2005-2008 Paul Mackerras
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
Use and redistribute under the terms of the GNU General Public License"] \
[PATCH] Improve look-and-feel of the gitk tool. Made the default buttons on the dialog active and focused upon the dialog appearence. Bound 'Escape' and 'Return' keys to the dialog dismissal where it was appropriate: mainly for dialogs with only one button and no editable fields. Unified the look of the "About gitk" and "Key bindings" dialogs. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-27 12:36:59 +02:00
-justify center -aspect 400 -border 2 -bg white -relief groove
pack $w.m -side top -fill x -padx 2 -pady 2
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $w.ok -text [mc "Close"] -command "destroy $w" -default active
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
pack $w.ok -side bottom
[PATCH] Improve look-and-feel of the gitk tool. Made the default buttons on the dialog active and focused upon the dialog appearence. Bound 'Escape' and 'Return' keys to the dialog dismissal where it was appropriate: mainly for dialogs with only one button and no editable fields. Unified the look of the "About gitk" and "Key bindings" dialogs. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-27 12:36:59 +02:00
bind $w <Visibility> "focus $w.ok"
bind $w <Key-Escape> "destroy $w"
bind $w <Key-Return> "destroy $w"
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
}
gitk: Add a help menu item to display key bindings Suggested by Paul Schulz. I made it a separate entry under the Help menu rather than putting it in the About box, though. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 01:39:51 +02:00
proc keys {} {
set w .keys
if {[winfo exists $w]} {
raise $w
return
}
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS git-gui already uses the command key for accelerators, but gitk has never done so. I'm actually finding it very hard to move back and forth between the two applications as git-gui is following the Mac OS X conventions and gitk is not. This trick is the same one that git-gui uses to determine which key to bind actions to. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-19 06:37:58 +02:00
if {[tk windowingsystem] eq {aqua}} {
set M1T Cmd
} else {
set M1T Ctrl
}
gitk: Add a help menu item to display key bindings Suggested by Paul Schulz. I made it a separate entry under the Help menu rather than putting it in the About box, though. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 01:39:51 +02:00
toplevel $w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
wm title $w [mc "Gitk key bindings"]
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $w .
[PATCH] gitk: Fix "Key bindings" message The "Key bindings" message under the "Help" menu was too long and could not be parsed by the translation engine. Fix both issues by translating one line at a time. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-15 23:31:49 +01:00
message $w.m -text "
[mc "Gitk key bindings:"]
[mc "<%s-Q> Quit" $M1T]
[mc "<Home> Move to first commit"]
[mc "<End> Move to last commit"]
[mc "<Up>, p, i Move up one commit"]
[mc "<Down>, n, k Move down one commit"]
[mc "<Left>, z, j Go back in history list"]
[mc "<Right>, x, l Go forward in history list"]
[mc "<PageUp> Move up one page in commit list"]
[mc "<PageDown> Move down one page in commit list"]
[mc "<%s-Home> Scroll to top of commit list" $M1T]
[mc "<%s-End> Scroll to bottom of commit list" $M1T]
[mc "<%s-Up> Scroll commit list up one line" $M1T]
[mc "<%s-Down> Scroll commit list down one line" $M1T]
[mc "<%s-PageUp> Scroll commit list up one page" $M1T]
[mc "<%s-PageDown> Scroll commit list down one page" $M1T]
[mc "<Shift-Up> Find backwards (upwards, later commits)"]
[mc "<Shift-Down> Find forwards (downwards, earlier commits)"]
[mc "<Delete>, b Scroll diff view up one page"]
[mc "<Backspace> Scroll diff view up one page"]
[mc "<Space> Scroll diff view down one page"]
[mc "u Scroll diff view up 18 lines"]
[mc "d Scroll diff view down 18 lines"]
[mc "<%s-F> Find" $M1T]
[mc "<%s-G> Move to next find hit" $M1T]
[mc "<Return> Move to next find hit"]
gitk: Map / to focus the search box The / key is often used to initiate searches (less, vim, some web browsers). This changes the binding for the / (slash) key from 'find next' to 'focus the search box' to follow this convention. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-02 02:19:22 +01:00
[mc "/ Focus the search box"]
[PATCH] gitk: Fix "Key bindings" message The "Key bindings" message under the "Help" menu was too long and could not be parsed by the translation engine. Fix both issues by translating one line at a time. Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-15 23:31:49 +01:00
[mc "? Move to previous find hit"]
[mc "f Scroll diff view to next file"]
[mc "<%s-S> Search for next hit in diff view" $M1T]
[mc "<%s-R> Search for previous hit in diff view" $M1T]
[mc "<%s-KP+> Increase font size" $M1T]
[mc "<%s-plus> Increase font size" $M1T]
[mc "<%s-KP-> Decrease font size" $M1T]
[mc "<%s-minus> Decrease font size" $M1T]
[mc "<F5> Update"]
" \
[PATCH] Improve look-and-feel of the gitk tool. Made the default buttons on the dialog active and focused upon the dialog appearence. Bound 'Escape' and 'Return' keys to the dialog dismissal where it was appropriate: mainly for dialogs with only one button and no editable fields. Unified the look of the "About gitk" and "Key bindings" dialogs. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-27 12:36:59 +02:00
-justify left -bg white -border 2 -relief groove
pack $w.m -side top -fill both -padx 2 -pady 2
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $w.ok -text [mc "Close"] -command "destroy $w" -default active
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $w <Key-Escape> [list destroy $w]
gitk: Add a help menu item to display key bindings Suggested by Paul Schulz. I made it a separate entry under the Help menu rather than putting it in the About box, though. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 01:39:51 +02:00
pack $w.ok -side bottom
[PATCH] Improve look-and-feel of the gitk tool. Made the default buttons on the dialog active and focused upon the dialog appearence. Bound 'Escape' and 'Return' keys to the dialog dismissal where it was appropriate: mainly for dialogs with only one button and no editable fields. Unified the look of the "About gitk" and "Key bindings" dialogs. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-27 12:36:59 +02:00
bind $w <Visibility> "focus $w.ok"
bind $w <Key-Escape> "destroy $w"
bind $w <Key-Return> "destroy $w"
gitk: Add a help menu item to display key bindings Suggested by Paul Schulz. I made it a separate entry under the Help menu rather than putting it in the About box, though. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 01:39:51 +02:00
}
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
# Procedures for manipulating the file list window at the
# bottom right of the overall window.
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
proc treeview {w l openlevs} {
global treecontents treediropen treeheight treeparent treeindex
set ix 0
set treeindex() 0
set lev 0
set prefix {}
set prefixend -1
set prefendstack {}
set htstack {}
set ht 0
set treecontents() {}
$w conf -state normal
foreach f $l {
while {[string range $f 0 $prefixend] ne $prefix} {
if {$lev <= $openlevs} {
$w mark set e:$treeindex($prefix) "end -1c"
$w mark gravity e:$treeindex($prefix) left
}
set treeheight($prefix) $ht
incr ht [lindex $htstack end]
set htstack [lreplace $htstack end end]
set prefixend [lindex $prefendstack end]
set prefendstack [lreplace $prefendstack end end]
set prefix [string range $prefix 0 $prefixend]
incr lev -1
}
set tail [string range $f [expr {$prefixend+1}] end]
while {[set slash [string first "/" $tail]] >= 0} {
lappend htstack $ht
set ht 0
lappend prefendstack $prefixend
incr prefixend [expr {$slash + 1}]
set d [string range $tail 0 $slash]
lappend treecontents($prefix) $d
set oldprefix $prefix
append prefix $d
set treecontents($prefix) {}
set treeindex($prefix) [incr ix]
set treeparent($prefix) $oldprefix
set tail [string range $tail [expr {$slash+1}] end]
if {$lev <= $openlevs} {
set ht 1
set treediropen($prefix) [expr {$lev < $openlevs}]
set bm [expr {$lev == $openlevs? "tri-rt": "tri-dn"}]
$w mark set d:$ix "end -1c"
$w mark gravity d:$ix left
set str "\n"
for {set i 0} {$i < $lev} {incr i} {append str "\t"}
$w insert end $str
$w image create end -align center -image $bm -padx 1 \
-name a:$ix
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$w insert end $d [highlight_tag $prefix]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
$w mark set s:$ix "end -1c"
$w mark gravity s:$ix left
}
incr lev
}
if {$tail ne {}} {
if {$lev <= $openlevs} {
incr ht
set str "\n"
for {set i 0} {$i < $lev} {incr i} {append str "\t"}
$w insert end $str
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$w insert end $tail [highlight_tag $f]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
lappend treecontents($prefix) $tail
}
}
while {$htstack ne {}} {
set treeheight($prefix) $ht
incr ht [lindex $htstack end]
set htstack [lreplace $htstack end end]
[PATCH] gitk: Fix for tree view ending in nested directories Unroll the prefix stack when assigning treeheights when leaving proc treeview. Previously, when the ls-tree output ended in multiple nested directories (for instance in a repository with a single file "foo/bar/baz"), $treeheight("foo/bar/") was assigned twice, and $treeheight("foo/") was never assigned. This led to an error when expanding the "foo" directory in the gitk treeview. Signed-off-by: Brian Downing <bdowning@lavos.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-05 13:33:02 +02:00
set prefixend [lindex $prefendstack end]
set prefendstack [lreplace $prefendstack end end]
set prefix [string range $prefix 0 $prefixend]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
$w conf -state disabled
}
proc linetoelt {l} {
global treeheight treecontents
set y 2
set prefix {}
while {1} {
foreach e $treecontents($prefix) {
if {$y == $l} {
return "$prefix$e"
}
set n 1
if {[string index $e end] eq "/"} {
set n $treeheight($prefix$e)
if {$y + $n > $l} {
append prefix $e
incr y
break
}
}
incr y $n
}
}
}
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
proc highlight_tree {y prefix} {
global treeheight treecontents cflist
foreach e $treecontents($prefix) {
set path $prefix$e
if {[highlight_tag $path] ne {}} {
$cflist tag add bold $y.0 "$y.0 lineend"
}
incr y
if {[string index $e end] eq "/" && $treeheight($path) > 1} {
set y [highlight_tree $y $path]
}
}
return $y
}
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
proc treeclosedir {w dir} {
global treediropen treeheight treeparent treeindex
set ix $treeindex($dir)
$w conf -state normal
$w delete s:$ix e:$ix
set treediropen($dir) 0
$w image configure a:$ix -image tri-rt
$w conf -state disabled
set n [expr {1 - $treeheight($dir)}]
while {$dir ne {}} {
incr treeheight($dir) $n
set dir $treeparent($dir)
}
}
proc treeopendir {w dir} {
global treediropen treeheight treeparent treecontents treeindex
set ix $treeindex($dir)
$w conf -state normal
$w image configure a:$ix -image tri-dn
$w mark set e:$ix s:$ix
$w mark gravity e:$ix right
set lev 0
set str "\n"
set n [llength $treecontents($dir)]
for {set x $dir} {$x ne {}} {set x $treeparent($x)} {
incr lev
append str "\t"
incr treeheight($x) $n
}
foreach e $treecontents($dir) {
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
set de $dir$e
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
if {[string index $e end] eq "/"} {
set iy $treeindex($de)
$w mark set d:$iy e:$ix
$w mark gravity d:$iy left
$w insert e:$ix $str
set treediropen($de) 0
$w image create e:$ix -align center -image tri-rt -padx 1 \
-name a:$iy
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$w insert e:$ix $e [highlight_tag $de]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
$w mark set s:$iy e:$ix
$w mark gravity s:$iy left
set treeheight($de) 1
} else {
$w insert e:$ix $str
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$w insert e:$ix $e [highlight_tag $de]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
}
gitk: Fix a bug in collapsing deeply nested trees To reproduce: expand a tree like this, then collapse A: +A +B C D The result is: -A C D I.e. sub-nodes expanded from the last sub-node of the item being collapsed are not removed. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-08 09:28:16 +02:00
$w mark gravity e:$ix right
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
$w conf -state disabled
set treediropen($dir) 1
set top [lindex [split [$w index @0,0] .] 0]
set ht [$w cget -height]
set l [lindex [split [$w index s:$ix] .] 0]
if {$l < $top} {
$w yview $l.0
} elseif {$l + $n + 1 > $top + $ht} {
set top [expr {$l + $n + 2 - $ht}]
if {$l < $top} {
set top $l
}
$w yview $top.0
}
}
proc treeclick {w x y} {
global treediropen cmitmode ctext cflist cflist_top
if {$cmitmode ne "tree"} return
if {![info exists cflist_top]} return
set l [lindex [split [$w index "@$x,$y"] "."] 0]
$cflist tag remove highlight $cflist_top.0 "$cflist_top.0 lineend"
$cflist tag add highlight $l.0 "$l.0 lineend"
set cflist_top $l
if {$l == 1} {
$ctext yview 1.0
return
}
set e [linetoelt $l]
if {[string index $e end] ne "/"} {
showfile $e
} elseif {$treediropen($e)} {
treeclosedir $w $e
} else {
treeopendir $w $e
}
}
proc setfilelist {id} {
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
global treefilelist cflist jump_to_here
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
treeview $cflist $treefilelist($id) 0
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
if {$jump_to_here ne {}} {
set f [lindex $jump_to_here 0]
if {[lsearch -exact $treefilelist($id) $f] >= 0} {
showfile $f
}
}
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
image create bitmap tri-rt -background black -foreground blue -data {
#define tri-rt_width 13
#define tri-rt_height 13
static unsigned char tri-rt_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x30, 0x00, 0x70, 0x00, 0xf0, 0x00,
0xf0, 0x01, 0xf0, 0x00, 0x70, 0x00, 0x30, 0x00, 0x10, 0x00, 0x00, 0x00,
0x00, 0x00};
} -maskdata {
#define tri-rt-mask_width 13
#define tri-rt-mask_height 13
static unsigned char tri-rt-mask_bits[] = {
0x08, 0x00, 0x18, 0x00, 0x38, 0x00, 0x78, 0x00, 0xf8, 0x00, 0xf8, 0x01,
0xf8, 0x03, 0xf8, 0x01, 0xf8, 0x00, 0x78, 0x00, 0x38, 0x00, 0x18, 0x00,
0x08, 0x00};
}
image create bitmap tri-dn -background black -foreground blue -data {
#define tri-dn_width 13
#define tri-dn_height 13
static unsigned char tri-dn_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfc, 0x07, 0xf8, 0x03,
0xf0, 0x01, 0xe0, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00};
} -maskdata {
#define tri-dn-mask_width 13
#define tri-dn-mask_height 13
static unsigned char tri-dn-mask_bits[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x1f, 0xfe, 0x0f, 0xfc, 0x07,
0xf8, 0x03, 0xf0, 0x01, 0xe0, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00};
}
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
image create bitmap reficon-T -background black -foreground yellow -data {
#define tagicon_width 13
#define tagicon_height 9
static unsigned char tagicon_bits[] = {
0x00, 0x00, 0x00, 0x00, 0xf0, 0x07, 0xf8, 0x07,
0xfc, 0x07, 0xf8, 0x07, 0xf0, 0x07, 0x00, 0x00, 0x00, 0x00};
} -maskdata {
#define tagicon-mask_width 13
#define tagicon-mask_height 9
static unsigned char tagicon-mask_bits[] = {
0x00, 0x00, 0xf0, 0x0f, 0xf8, 0x0f, 0xfc, 0x0f,
0xfe, 0x0f, 0xfc, 0x0f, 0xf8, 0x0f, 0xf0, 0x0f, 0x00, 0x00};
}
set rectdata {
#define headicon_width 13
#define headicon_height 9
static unsigned char headicon_bits[] = {
0x00, 0x00, 0x00, 0x00, 0xf8, 0x07, 0xf8, 0x07,
0xf8, 0x07, 0xf8, 0x07, 0xf8, 0x07, 0x00, 0x00, 0x00, 0x00};
}
set rectmask {
#define headicon-mask_width 13
#define headicon-mask_height 9
static unsigned char headicon-mask_bits[] = {
0x00, 0x00, 0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f,
0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f, 0xfc, 0x0f, 0x00, 0x00};
}
image create bitmap reficon-H -background black -foreground green \
-data $rectdata -maskdata $rectmask
image create bitmap reficon-o -background black -foreground "#ddddff" \
-data $rectdata -maskdata $rectmask
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
proc init_flist {first} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global cflist cflist_top difffilestart
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
$cflist conf -state normal
$cflist delete 0.0 end
if {$first ne {}} {
$cflist insert end $first
set cflist_top 1
$cflist tag add highlight 1.0 "1.0 lineend"
} else {
catch {unset cflist_top}
}
$cflist conf -state disabled
set difffilestart {}
}
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
proc highlight_tag {f} {
global highlight_paths
foreach p $highlight_paths {
if {[string match $p $f]} {
return "bold"
}
}
return {}
}
proc highlight_filelist {} {
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
global cmitmode cflist
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$cflist conf -state normal
if {$cmitmode ne "tree"} {
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
set end [lindex [split [$cflist index end] .] 0]
for {set l 2} {$l < $end} {incr l} {
set line [$cflist get $l.0 "$l.0 lineend"]
if {[highlight_tag $line] ne {}} {
$cflist tag add bold $l.0 "$l.0 lineend"
}
}
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
} else {
highlight_tree 2 {}
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
}
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$cflist conf -state disabled
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
}
proc unhighlight_filelist {} {
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
global cflist
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$cflist conf -state normal
$cflist tag remove bold 1.0 end
$cflist conf -state disabled
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
}
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
proc add_flist {fl} {
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
global cflist
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$cflist conf -state normal
foreach f $fl {
$cflist insert end "\n"
$cflist insert end $f [highlight_tag $f]
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
}
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
$cflist conf -state disabled
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
}
proc sel_flist {w x y} {
gitk: Highlight paths of interest in tree view as well With this, when the file list window is in tree view mode, we highlight the paths of interest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 14:56:27 +02:00
global ctext difffilestart cflist cflist_top cmitmode
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
if {$cmitmode eq "tree"} return
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
if {![info exists cflist_top]} return
set l [lindex [split [$w index "@$x,$y"] "."] 0]
gitk: Fix file list display when files are renamed The conversion of the file list to use a text widget assumed incorrectly that the list of files from git-diff-tree -r would correspond 1-1 with the diff sections in the output of git-diff-tree -r -p -C, which is not true when renames are detected. This fixes it by keeping the elements in the difffilestart list in the order they appear in the file list window. Since this means that the elements of difffilestart are no longer necessarily in ascending order, it's somewhat hard to do the dynamic highlighting in the file list as the diff window is scrolled, so I have taken that out for now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 11:55:31 +02:00
$cflist tag remove highlight $cflist_top.0 "$cflist_top.0 lineend"
$cflist tag add highlight $l.0 "$l.0 lineend"
set cflist_top $l
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
if {$l == 1} {
$ctext yview 1.0
} else {
catch {$ctext yview [lindex $difffilestart [expr {$l - 2}]]}
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
}
}
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
proc pop_flist_menu {w X Y x y} {
global ctext cflist cmitmode flist_menu flist_menu_file
global treediffs diffids
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
stopfinding
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
set l [lindex [split [$w index "@$x,$y"] "."] 0]
if {$l <= 1} return
if {$cmitmode eq "tree"} {
set e [linetoelt $l]
if {[string index $e end] eq "/"} return
} else {
set e [lindex $treediffs($diffids) [expr {$l-2}]]
}
set flist_menu_file $e
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
set xdiffstate "normal"
if {$cmitmode eq "tree"} {
set xdiffstate "disabled"
}
# Disable "External diff" item in tree mode
$flist_menu entryconf 2 -state $xdiffstate
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
tk_popup $flist_menu $X $Y
}
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
proc find_ctext_fileinfo {line} {
global ctext_file_names ctext_file_lines
set ok [bsearch $ctext_file_lines $line]
set tline [lindex $ctext_file_lines $ok]
if {$ok >= [llength $ctext_file_lines] || $line < $tline} {
return {}
} else {
return [list [lindex $ctext_file_names $ok] $tline]
}
}
proc pop_diff_menu {w X Y x y} {
global ctext diff_menu flist_menu_file
global diff_menu_txtpos diff_menu_line
global diff_menu_filebase
set diff_menu_txtpos [split [$w index "@$x,$y"] "."]
set diff_menu_line [lindex $diff_menu_txtpos 0]
gitk: Fix some off-by-one errors in computing which line to blame When walking back from the line where a right-click happened to the previous hunk separator line to calculate the line number to work on, we were counting every line including the one clicked on. That isn't right; if the user clicked on the line immediately after the hunk separator then the correct line number would be the one from the hunk separator. Therefore this looks at the clicked-on line to work out which parent to blame (or whether to blame the current commit), and then looks only at the preceding lines to work out the offset from the line number in the hunk separator. This also fixes an off-by-one error when we are showing files rather than diffs. In this case diff_menu_filebase is the line number of the banner showing the file name, so the first line of the file is at line $diff_menu_filebase + 1. This also simplifies the code in find_hunk_blamespec a bit and arranges that we don't pop up the context menu if the user clicks on a file separator line or a hunk separator line. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:13:37 +01:00
# don't pop up the menu on hunk-separator or file-separator lines
if {[lsearch -glob [$ctext tag names $diff_menu_line.0] "*sep"] >= 0} {
return
}
stopfinding
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
set f [find_ctext_fileinfo $diff_menu_line]
if {$f eq {}} return
set flist_menu_file [lindex $f 0]
set diff_menu_filebase [lindex $f 1]
tk_popup $diff_menu $X $Y
}
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
proc flist_hl {only} {
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
global flist_menu_file findstring gdttype
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
set x [shellquote $flist_menu_file]
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$only || $findstring eq {} || $gdttype ne [mc "touching paths:"]} {
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
set findstring $x
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
} else {
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
append findstring " " $x
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
}
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set gdttype [mc "touching paths:"]
gitk: Add a context menu for file list entries At the moment this just has two entries, which allow you to add the file that you clicked on to the list of filenames to highlight, or replace the list with the file. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-27 14:30:15 +02:00
}
gitk: Show diff of commits at end of compare-commits output When comparing a string of commits, when we find two non-merge commits that differ, we now write the two commits to files and diff the files. This pulls out the logic for creating a temporary directory from external_diff into a separate procedure so that the new diffcommits procedure can use it. Because the diff command returns an exit status of 1 when the files differ, and Tcl treats that as an error, this adds catch {} around the close statements in getblobdiffline. At present this only removes the temporary files when gitk exits. It should remove them when the diff is done. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-07 02:08:21 +02:00
proc gitknewtmpdir {} {
global diffnum gitktmpdir gitdir
if {![info exists gitktmpdir]} {
set gitktmpdir [file join [file dirname $gitdir] \
[format ".gitk-tmp.%s" [pid]]]
if {[catch {file mkdir $gitktmpdir} err]} {
error_popup "[mc "Error creating temporary directory %s:" $gitktmpdir] $err"
unset gitktmpdir
return {}
}
set diffnum 0
}
incr diffnum
set diffdir [file join $gitktmpdir $diffnum]
if {[catch {file mkdir $diffdir} err]} {
error_popup "[mc "Error creating temporary directory %s:" $diffdir] $err"
return {}
}
return $diffdir
}
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
proc save_file_from_commit {filename output what} {
global nullfile
if {[catch {exec git show $filename -- > $output} err]} {
if {[string match "fatal: bad revision *" $err]} {
return $nullfile
}
gitk: Add untranslated error messages to translation Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-12 11:39:43 +02:00
error_popup "[mc "Error getting \"%s\" from %s:" $filename $what] $err"
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
return {}
}
return $output
}
proc external_diff_get_one_file {diffid filename diffdir} {
global nullid nullid2 nullfile
global gitdir
if {$diffid == $nullid} {
set difffile [file join [file dirname $gitdir] $filename]
if {[file exists $difffile]} {
return $difffile
}
return $nullfile
}
if {$diffid == $nullid2} {
set difffile [file join $diffdir "\[index\] [file tail $filename]"]
return [save_file_from_commit :$filename $difffile index]
}
set difffile [file join $diffdir "\[$diffid\] [file tail $filename]"]
return [save_file_from_commit $diffid:$filename $difffile \
"revision $diffid"]
}
proc external_diff {} {
gitk: Show diff of commits at end of compare-commits output When comparing a string of commits, when we find two non-merge commits that differ, we now write the two commits to files and diff the files. This pulls out the logic for creating a temporary directory from external_diff into a separate procedure so that the new diffcommits procedure can use it. Because the diff command returns an exit status of 1 when the files differ, and Tcl treats that as an error, this adds catch {} around the close statements in getblobdiffline. At present this only removes the temporary files when gitk exits. It should remove them when the diff is done. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-07 02:08:21 +02:00
global nullid nullid2
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
global flist_menu_file
global diffids
gitk: Show diff of commits at end of compare-commits output When comparing a string of commits, when we find two non-merge commits that differ, we now write the two commits to files and diff the files. This pulls out the logic for creating a temporary directory from external_diff into a separate procedure so that the new diffcommits procedure can use it. Because the diff command returns an exit status of 1 when the files differ, and Tcl treats that as an error, this adds catch {} around the close statements in getblobdiffline. At present this only removes the temporary files when gitk exits. It should remove them when the diff is done. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-07 02:08:21 +02:00
global extdifftool
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
if {[llength $diffids] == 1} {
# no reference commit given
set diffidto [lindex $diffids 0]
if {$diffidto eq $nullid} {
# diffing working copy with index
set diffidfrom $nullid2
} elseif {$diffidto eq $nullid2} {
# diffing index with HEAD
set diffidfrom "HEAD"
} else {
# use first parent commit
global parentlist selectedline
set diffidfrom [lindex $parentlist $selectedline 0]
}
} else {
set diffidfrom [lindex $diffids 0]
set diffidto [lindex $diffids 1]
}
# make sure that several diffs wont collide
gitk: Show diff of commits at end of compare-commits output When comparing a string of commits, when we find two non-merge commits that differ, we now write the two commits to files and diff the files. This pulls out the logic for creating a temporary directory from external_diff into a separate procedure so that the new diffcommits procedure can use it. Because the diff command returns an exit status of 1 when the files differ, and Tcl treats that as an error, this adds catch {} around the close statements in getblobdiffline. At present this only removes the temporary files when gitk exits. It should remove them when the diff is done. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-07 02:08:21 +02:00
set diffdir [gitknewtmpdir]
if {$diffdir eq {}} return
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
# gather files to diff
set difffromfile [external_diff_get_one_file $diffidfrom $flist_menu_file $diffdir]
set difftofile [external_diff_get_one_file $diffidto $flist_menu_file $diffdir]
if {$difffromfile ne {} && $difftofile ne {}} {
gitk: Handle external diff tool with spaces in the path This fixes the launching of external diff to handle a diff tool that has spaces in the path. This ensures a correctly formed tcl list is passed to the open command with a single pipe character prefixing the list (as per the tcl manual page for open). The specific fault observed was that selecting WinMerge as the diff tool from the default installed location in Program Files failed to be launched from the context menu. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-15 17:54:19 +02:00
set cmd [list [shellsplit $extdifftool] $difffromfile $difftofile]
if {[catch {set fl [open |$cmd r]} err]} {
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
file delete -force $diffdir
gitk: Add untranslated error messages to translation Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-12 11:39:43 +02:00
error_popup "$extdifftool: [mc "command failed:"] $err"
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
} else {
fconfigure $fl -blocking 0
filerun $fl [list delete_at_eof $fl $diffdir]
}
}
}
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
proc find_hunk_blamespec {base line} {
global ctext
# Find and parse the hunk header
set s_lix [$ctext search -backwards -regexp ^@@ "$line.0 lineend" $base.0]
if {$s_lix eq {}} return
set s_line [$ctext get $s_lix "$s_lix + 1 lines"]
if {![regexp {^@@@*(( -\d+(,\d+)?)+) \+(\d+)(,\d+)? @@} $s_line \
s_line old_specs osz osz1 new_line nsz]} {
return
}
# base lines for the parents
set base_lines [list $new_line]
foreach old_spec [lrange [split $old_specs " "] 1 end] {
if {![regexp -- {-(\d+)(,\d+)?} $old_spec \
old_spec old_line osz]} {
return
}
lappend base_lines $old_line
}
# Now scan the lines to determine offset within the hunk
set max_parent [expr {[llength $base_lines]-2}]
set dline 0
set s_lno [lindex [split $s_lix "."] 0]
gitk: Fix some off-by-one errors in computing which line to blame When walking back from the line where a right-click happened to the previous hunk separator line to calculate the line number to work on, we were counting every line including the one clicked on. That isn't right; if the user clicked on the line immediately after the hunk separator then the correct line number would be the one from the hunk separator. Therefore this looks at the clicked-on line to work out which parent to blame (or whether to blame the current commit), and then looks only at the preceding lines to work out the offset from the line number in the hunk separator. This also fixes an off-by-one error when we are showing files rather than diffs. In this case diff_menu_filebase is the line number of the banner showing the file name, so the first line of the file is at line $diff_menu_filebase + 1. This also simplifies the code in find_hunk_blamespec a bit and arranges that we don't pop up the context menu if the user clicks on a file separator line or a hunk separator line. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:13:37 +01:00
# Determine if the line is removed
set chunk [$ctext get $line.0 "$line.1 + $max_parent chars"]
if {[string match {[-+ ]*} $chunk]} {
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
set removed_idx [string first "-" $chunk]
# Choose a parent index
gitk: Fix some off-by-one errors in computing which line to blame When walking back from the line where a right-click happened to the previous hunk separator line to calculate the line number to work on, we were counting every line including the one clicked on. That isn't right; if the user clicked on the line immediately after the hunk separator then the correct line number would be the one from the hunk separator. Therefore this looks at the clicked-on line to work out which parent to blame (or whether to blame the current commit), and then looks only at the preceding lines to work out the offset from the line number in the hunk separator. This also fixes an off-by-one error when we are showing files rather than diffs. In this case diff_menu_filebase is the line number of the banner showing the file name, so the first line of the file is at line $diff_menu_filebase + 1. This also simplifies the code in find_hunk_blamespec a bit and arranges that we don't pop up the context menu if the user clicks on a file separator line or a hunk separator line. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:13:37 +01:00
if {$removed_idx >= 0} {
set parent $removed_idx
} else {
set unchanged_idx [string first " " $chunk]
if {$unchanged_idx >= 0} {
set parent $unchanged_idx
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
} else {
gitk: Fix some off-by-one errors in computing which line to blame When walking back from the line where a right-click happened to the previous hunk separator line to calculate the line number to work on, we were counting every line including the one clicked on. That isn't right; if the user clicked on the line immediately after the hunk separator then the correct line number would be the one from the hunk separator. Therefore this looks at the clicked-on line to work out which parent to blame (or whether to blame the current commit), and then looks only at the preceding lines to work out the offset from the line number in the hunk separator. This also fixes an off-by-one error when we are showing files rather than diffs. In this case diff_menu_filebase is the line number of the banner showing the file name, so the first line of the file is at line $diff_menu_filebase + 1. This also simplifies the code in find_hunk_blamespec a bit and arranges that we don't pop up the context menu if the user clicks on a file separator line or a hunk separator line. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:13:37 +01:00
# blame the current commit
set parent -1
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
}
}
# then count other lines that belong to it
gitk: Fix some off-by-one errors in computing which line to blame When walking back from the line where a right-click happened to the previous hunk separator line to calculate the line number to work on, we were counting every line including the one clicked on. That isn't right; if the user clicked on the line immediately after the hunk separator then the correct line number would be the one from the hunk separator. Therefore this looks at the clicked-on line to work out which parent to blame (or whether to blame the current commit), and then looks only at the preceding lines to work out the offset from the line number in the hunk separator. This also fixes an off-by-one error when we are showing files rather than diffs. In this case diff_menu_filebase is the line number of the banner showing the file name, so the first line of the file is at line $diff_menu_filebase + 1. This also simplifies the code in find_hunk_blamespec a bit and arranges that we don't pop up the context menu if the user clicks on a file separator line or a hunk separator line. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:13:37 +01:00
for {set i $line} {[incr i -1] > $s_lno} {} {
set chunk [$ctext get $i.0 "$i.1 + $max_parent chars"]
# Determine if the line is removed
set removed_idx [string first "-" $chunk]
if {$parent >= 0} {
set code [string index $chunk $parent]
if {$code eq "-" || ($removed_idx < 0 && $code ne "+")} {
incr dline
}
} else {
if {$removed_idx < 0} {
incr dline
}
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
}
}
gitk: Fix some off-by-one errors in computing which line to blame When walking back from the line where a right-click happened to the previous hunk separator line to calculate the line number to work on, we were counting every line including the one clicked on. That isn't right; if the user clicked on the line immediately after the hunk separator then the correct line number would be the one from the hunk separator. Therefore this looks at the clicked-on line to work out which parent to blame (or whether to blame the current commit), and then looks only at the preceding lines to work out the offset from the line number in the hunk separator. This also fixes an off-by-one error when we are showing files rather than diffs. In this case diff_menu_filebase is the line number of the banner showing the file name, so the first line of the file is at line $diff_menu_filebase + 1. This also simplifies the code in find_hunk_blamespec a bit and arranges that we don't pop up the context menu if the user clicks on a file separator line or a hunk separator line. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:13:37 +01:00
incr parent
} else {
set parent 0
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
}
incr dline [lindex $base_lines $parent]
return [list $parent $dline]
}
proc external_blame_diff {} {
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
global currentid cmitmode
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
global diff_menu_txtpos diff_menu_line
global diff_menu_filebase flist_menu_file
if {$cmitmode eq "tree"} {
set parent_idx 0
gitk: Fix some off-by-one errors in computing which line to blame When walking back from the line where a right-click happened to the previous hunk separator line to calculate the line number to work on, we were counting every line including the one clicked on. That isn't right; if the user clicked on the line immediately after the hunk separator then the correct line number would be the one from the hunk separator. Therefore this looks at the clicked-on line to work out which parent to blame (or whether to blame the current commit), and then looks only at the preceding lines to work out the offset from the line number in the hunk separator. This also fixes an off-by-one error when we are showing files rather than diffs. In this case diff_menu_filebase is the line number of the banner showing the file name, so the first line of the file is at line $diff_menu_filebase + 1. This also simplifies the code in find_hunk_blamespec a bit and arranges that we don't pop up the context menu if the user clicks on a file separator line or a hunk separator line. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:13:37 +01:00
set line [expr {$diff_menu_line - $diff_menu_filebase}]
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
} else {
set hinfo [find_hunk_blamespec $diff_menu_filebase $diff_menu_line]
if {$hinfo ne {}} {
set parent_idx [lindex $hinfo 0]
set line [lindex $hinfo 1]
} else {
set parent_idx 0
set line 0
}
}
external_blame $parent_idx $line
}
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
# Find the SHA1 ID of the blob for file $fname in the index
# at stage 0 or 2
proc index_sha1 {fname} {
set f [open [list | git ls-files -s $fname] r]
while {[gets $f line] >= 0} {
set info [lindex [split $line "\t"] 0]
set stage [lindex $info 2]
if {$stage eq "0" || $stage eq "2"} {
close $f
return [lindex $info 1]
}
}
close $f
return {}
}
gitk: Fix bugs in blaming code The "show origin of this line" function wasn't working when gitk was run in a subdirectory, since it passed the path relative to the top-level directory to git blame. This fixes it by passing the absolute path to the file instead of the relative path. The same problem occurs when running git gui blame, except that git gui blame appears not to be able to accept an absolute path to the file, so we make a relative path using a new [make_relative] function. Finally, this fixes a bug in [show_line_source] where we weren't setting id, resulting in an error when trying to find the origin of a line in the fake commit for local changes not checked in, when its parent was a real commit (i.e. there were no changes checked in). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 11:44:05 +01:00
# Turn an absolute path into one relative to the current directory
proc make_relative {f} {
set elts [file split $f]
set here [file split [pwd]]
set ei 0
set hi 0
set res {}
foreach d $here {
if {$ei < $hi || $ei >= [llength $elts] || [lindex $elts $ei] ne $d} {
lappend res ".."
} else {
incr ei
}
incr hi
}
set elts [concat $res [lrange $elts $ei end]]
return [eval file join $elts]
}
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
proc external_blame {parent_idx {line {}}} {
gitk: Fix bugs in blaming code The "show origin of this line" function wasn't working when gitk was run in a subdirectory, since it passed the path relative to the top-level directory to git blame. This fixes it by passing the absolute path to the file instead of the relative path. The same problem occurs when running git gui blame, except that git gui blame appears not to be able to accept an absolute path to the file, so we make a relative path using a new [make_relative] function. Finally, this fixes a bug in [show_line_source] where we weren't setting id, resulting in an error when trying to find the origin of a line in the fake commit for local changes not checked in, when its parent was a real commit (i.e. there were no changes checked in). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 11:44:05 +01:00
global flist_menu_file gitdir
gitk: Add menu item for calling git gui blame This adds a new item to the file list popup menu, that calls git gui blame for the selected file, starting with the first parent of the current commit. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:29:08 +02:00
global nullid nullid2
global parentlist selectedline currentid
if {$parent_idx > 0} {
set base_commit [lindex $parentlist $selectedline [expr {$parent_idx-1}]]
} else {
set base_commit $currentid
}
if {$base_commit eq {} || $base_commit eq $nullid || $base_commit eq $nullid2} {
error_popup [mc "No such commit"]
return
}
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
set cmdline [list git gui blame]
if {$line ne {} && $line > 1} {
lappend cmdline "--line=$line"
}
gitk: Fix bugs in blaming code The "show origin of this line" function wasn't working when gitk was run in a subdirectory, since it passed the path relative to the top-level directory to git blame. This fixes it by passing the absolute path to the file instead of the relative path. The same problem occurs when running git gui blame, except that git gui blame appears not to be able to accept an absolute path to the file, so we make a relative path using a new [make_relative] function. Finally, this fixes a bug in [show_line_source] where we weren't setting id, resulting in an error when trying to find the origin of a line in the fake commit for local changes not checked in, when its parent was a real commit (i.e. there were no changes checked in). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 11:44:05 +01:00
set f [file join [file dirname $gitdir] $flist_menu_file]
# Unfortunately it seems git gui blame doesn't like
# being given an absolute path...
set f [make_relative $f]
lappend cmdline $base_commit $f
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
if {[catch {eval exec $cmdline &} err]} {
gitk: Add untranslated error messages to translation Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-12 11:39:43 +02:00
error_popup "[mc "git gui blame: command failed:"] $err"
gitk: Add menu item for calling git gui blame This adds a new item to the file list popup menu, that calls git gui blame for the selected file, starting with the first parent of the current commit. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:29:08 +02:00
}
}
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
proc show_line_source {} {
global cmitmode currentid parents curview blamestuff blameinst
global diff_menu_line diff_menu_filebase flist_menu_file
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
global nullid nullid2 gitdir
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
set from_index {}
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
if {$cmitmode eq "tree"} {
set id $currentid
set line [expr {$diff_menu_line - $diff_menu_filebase}]
} else {
set h [find_hunk_blamespec $diff_menu_filebase $diff_menu_line]
if {$h eq {}} return
set pi [lindex $h 0]
if {$pi == 0} {
mark_ctext_line $diff_menu_line
return
}
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
incr pi -1
if {$currentid eq $nullid} {
if {$pi > 0} {
# must be a merge in progress...
if {[catch {
# get the last line from .git/MERGE_HEAD
set f [open [file join $gitdir MERGE_HEAD] r]
set id [lindex [split [read $f] "\n"] end-1]
close $f
} err]} {
error_popup [mc "Couldn't read merge head: %s" $err]
return
}
} elseif {$parents($curview,$currentid) eq $nullid2} {
# need to do the blame from the index
if {[catch {
set from_index [index_sha1 $flist_menu_file]
} err]} {
error_popup [mc "Error reading index: %s" $err]
return
}
gitk: Fix bugs in blaming code The "show origin of this line" function wasn't working when gitk was run in a subdirectory, since it passed the path relative to the top-level directory to git blame. This fixes it by passing the absolute path to the file instead of the relative path. The same problem occurs when running git gui blame, except that git gui blame appears not to be able to accept an absolute path to the file, so we make a relative path using a new [make_relative] function. Finally, this fixes a bug in [show_line_source] where we weren't setting id, resulting in an error when trying to find the origin of a line in the fake commit for local changes not checked in, when its parent was a real commit (i.e. there were no changes checked in). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 11:44:05 +01:00
} else {
set id $parents($curview,$currentid)
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
}
} else {
set id [lindex $parents($curview,$currentid) $pi]
}
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
set line [lindex $h 1]
}
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
set blameargs {}
if {$from_index ne {}} {
lappend blameargs | git cat-file blob $from_index
}
lappend blameargs | git blame -p -L$line,+1
if {$from_index ne {}} {
lappend blameargs --contents -
} else {
lappend blameargs $id
}
gitk: Fix bugs in blaming code The "show origin of this line" function wasn't working when gitk was run in a subdirectory, since it passed the path relative to the top-level directory to git blame. This fixes it by passing the absolute path to the file instead of the relative path. The same problem occurs when running git gui blame, except that git gui blame appears not to be able to accept an absolute path to the file, so we make a relative path using a new [make_relative] function. Finally, this fixes a bug in [show_line_source] where we weren't setting id, resulting in an error when trying to find the origin of a line in the fake commit for local changes not checked in, when its parent was a real commit (i.e. there were no changes checked in). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 11:44:05 +01:00
lappend blameargs -- [file join [file dirname $gitdir] $flist_menu_file]
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
if {[catch {
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
set f [open $blameargs r]
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
} err]} {
error_popup [mc "Couldn't start git blame: %s" $err]
return
}
gitk: Make line origin search update the busy status Currently the 'show origin of this line' feature does not update the status field of the gitk window, so it is not evident that any processing is going on. It may seem at first that clicking the item had no effect. This commit adds calls to set and clear the busy status with an appropriate title, similar to other search commands. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-01 18:30:09 +01:00
nowbusy blaming [mc "Searching"]
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
fconfigure $f -blocking 0
set i [reg_instance $f]
set blamestuff($i) {}
set blameinst $i
filerun $f [list read_line_source $f $i]
}
proc stopblaming {} {
global blameinst
if {[info exists blameinst]} {
stop_instance $blameinst
unset blameinst
gitk: Make line origin search update the busy status Currently the 'show origin of this line' feature does not update the status field of the gitk window, so it is not evident that any processing is going on. It may seem at first that clicking the item had no effect. This commit adds calls to set and clear the busy status with an appropriate title, similar to other search commands. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-01 18:30:09 +01:00
notbusy blaming
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
}
}
proc read_line_source {fd inst} {
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
global blamestuff curview commfd blameinst nullid nullid2
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
while {[gets $fd line] >= 0} {
lappend blamestuff($inst) $line
}
if {![eof $fd]} {
return 1
}
unset commfd($inst)
unset blameinst
gitk: Make line origin search update the busy status Currently the 'show origin of this line' feature does not update the status field of the gitk window, so it is not evident that any processing is going on. It may seem at first that clicking the item had no effect. This commit adds calls to set and clear the busy status with an appropriate title, similar to other search commands. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-01 18:30:09 +01:00
notbusy blaming
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
fconfigure $fd -blocking 1
if {[catch {close $fd} err]} {
error_popup [mc "Error running git blame: %s" $err]
return 0
}
set fname {}
set line [split [lindex $blamestuff($inst) 0] " "]
set id [lindex $line 0]
set lnum [lindex $line 1]
if {[string length $id] == 40 && [string is xdigit $id] &&
[string is digit -strict $lnum]} {
# look for "filename" line
foreach l $blamestuff($inst) {
if {[string match "filename *" $l]} {
set fname [string range $l 9 end]
break
}
}
}
if {$fname ne {}} {
# all looks good, select it
gitk: Make "show origin of this line" work on fake commits This makes the "Show origin of this line" menu item work correctly on the fake commits that gitk shows for local uncommitted changes. With the fake commit for changes that aren't checked in to the index, we can actually get a 3-way diff shown, which means we might have to blame either the parent or the commit being merged in (which we get from .git/MERGE_HEAD). If the parent is the fake commit which shows the changes that have been checked in to the index, then we need to get the SHA1 of the blob for the version of the file that is in the index, then use git cat-file blob to get the contents of the blob, and give that to git blame with --contents - so that git blame will do the blame on the index version of the file. In that case, we might get the all-zeroes SHA1 back from git blame, meaning that the line is new in the index version of the file, so then we have to use $nullid2 (the pseudo-SHA1 of the fake commit for the checked-in changes). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 02:57:44 +01:00
if {$id eq $nullid} {
# blame uses all-zeroes to mean not committed,
# which would mean a change in the index
set id $nullid2
}
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
if {[commitinview $id $curview]} {
selectline [rowofcommit $id] 1 [list $fname $lnum]
} else {
error_popup [mc "That line comes from commit %s, \
which is not in this view" [shortids $id]]
}
} else {
puts "oops couldn't parse git blame output"
}
return 0
}
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
# delete $dir when we see eof on $f (presumably because the child has exited)
proc delete_at_eof {f dir} {
while {[gets $f line] >= 0} {}
if {[eof $f]} {
if {[catch {close $f} err]} {
gitk: Add untranslated error messages to translation Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-12 11:39:43 +02:00
error_popup "[mc "External diff viewer failed:"] $err"
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
}
file delete -force $dir
return 0
}
return 1
}
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
# Functions for adding and removing shell-type quoting
proc shellquote {str} {
if {![string match "*\['\"\\ \t]*" $str]} {
return $str
}
if {![string match "*\['\"\\]*" $str]} {
return "\"$str\""
}
if {![string match "*'*" $str]} {
return "'$str'"
}
return "\"[string map {\" \\\" \\ \\\\} $str]\""
}
proc shellarglist {l} {
set str {}
foreach a $l {
if {$str ne {}} {
append str " "
}
append str [shellquote $a]
}
return $str
}
proc shelldequote {str} {
set ret {}
set used -1
while {1} {
incr used
if {![regexp -start $used -indices "\['\"\\\\ \t]" $str first]} {
append ret [string range $str $used end]
set used [string length $str]
break
}
set first [lindex $first 0]
set ch [string index $str $first]
if {$first > $used} {
append ret [string range $str $used [expr {$first - 1}]]
set used $first
}
if {$ch eq " " || $ch eq "\t"} break
incr used
if {$ch eq "'"} {
set first [string first "'" $str $used]
if {$first < 0} {
error "unmatched single-quote"
}
append ret [string range $str $used [expr {$first - 1}]]
set used $first
continue
}
if {$ch eq "\\"} {
if {$used >= [string length $str]} {
error "trailing backslash"
}
append ret [string index $str $used]
continue
}
# here ch == "\""
while {1} {
if {![regexp -start $used -indices "\[\"\\\\]" $str first]} {
error "unmatched double-quote"
}
set first [lindex $first 0]
set ch [string index $str $first]
if {$first > $used} {
append ret [string range $str $used [expr {$first - 1}]]
set used $first
}
if {$ch eq "\""} break
incr used
append ret [string index $str $used]
incr used
}
}
return [list $used $ret]
}
proc shellsplit {str} {
set l {}
while {1} {
set str [string trimleft $str]
if {$str eq {}} break
set dq [shelldequote $str]
set n [lindex $dq 0]
set word [lindex $dq 1]
set str [string range $str $n end]
lappend l $word
}
return $l
}
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
# Code to implement multiple views
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
proc newview {ishighlight} {
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
global nextviewnum newviewname newishighlight
global revtreeargs viewargscmd newviewopts curview
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
set newishighlight $ishighlight
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set top .gitkview
if {[winfo exists $top]} {
raise $top
return
}
[PATCH] gitk: Mark another string for translation Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 21:12:47 +01:00
set newviewname($nextviewnum) "[mc "View"] $nextviewnum"
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set newviewopts($nextviewnum,perm) 0
set newviewopts($nextviewnum,cmd) $viewargscmd($curview)
decode_view_opts $nextviewnum $revtreeargs
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
vieweditor $top $nextviewnum [mc "Gitk view definition"]
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
}
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set known_view_options {
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
{perm b . {} {mc "Remember this view"}}
{reflabel l + {} {mc "References (space separated list):"}}
{refs t15 .. {} {mc "Branches & tags:"}}
{allrefs b *. "--all" {mc "All refs"}}
{branches b . "--branches" {mc "All (local) branches"}}
{tags b . "--tags" {mc "All tags"}}
{remotes b . "--remotes" {mc "All remote-tracking branches"}}
{commitlbl l + {} {mc "Commit Info (regular expressions):"}}
{author t15 .. "--author=*" {mc "Author:"}}
{committer t15 . "--committer=*" {mc "Committer:"}}
{loginfo t15 .. "--grep=*" {mc "Commit Message:"}}
{allmatch b .. "--all-match" {mc "Matches all Commit Info criteria"}}
{changes_l l + {} {mc "Changes to Files:"}}
{pickaxe_s r0 . {} {mc "Fixed String"}}
{pickaxe_t r1 . "--pickaxe-regex" {mc "Regular Expression"}}
{pickaxe t15 .. "-S*" {mc "Search string:"}}
{datelabel l + {} {mc "Commit Dates (\"2 weeks ago\", \"2009-03-17 15:27:38\", \"March 17, 2009 15:27:38\"):"}}
{since t15 .. {"--since=*" "--after=*"} {mc "Since:"}}
{until t15 . {"--until=*" "--before=*"} {mc "Until:"}}
{limit_lbl l + {} {mc "Limit and/or skip a number of revisions (positive integer):"}}
{limit t10 *. "--max-count=*" {mc "Number to show:"}}
{skip t10 . "--skip=*" {mc "Number to skip:"}}
{misc_lbl l + {} {mc "Miscellaneous options:"}}
{dorder b *. {"--date-order" "-d"} {mc "Strictly sort by date"}}
{lright b . "--left-right" {mc "Mark branch sides"}}
{first b . "--first-parent" {mc "Limit to first parent"}}
gitk: Add option 'Simple history' to the options menu When clicked, the option --simplify-by-decoration is added to gitk/git log. This yields to a simplified history where only decorated commits are shown, i.e. those with a yellow tag or a green branch flag. Signed-off-by: Dirk Suesserott <newsletter@dirk.my1.cc> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-05-21 15:35:40 +02:00
{smplhst b . "--simplify-by-decoration" {mc "Simple history"}}
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
{args t50 *. {} {mc "Additional arguments to git log:"}}
{allpaths path + {} {mc "Enter files and directories to include, one per line:"}}
{cmd t50= + {} {mc "Command to generate more commits to include:"}}
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
}
proc encode_view_opts {n} {
global known_view_options newviewopts
set rargs [list]
foreach opt $known_view_options {
set patterns [lindex $opt 3]
if {$patterns eq {}} continue
set pattern [lindex $patterns 0]
if {[lindex $opt 1] eq "b"} {
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
set val $newviewopts($n,[lindex $opt 0])
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
if {$val} {
lappend rargs $pattern
}
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
} elseif {[regexp {^r(\d+)$} [lindex $opt 1] type value]} {
regexp {^(.*_)} [lindex $opt 0] uselessvar button_id
set val $newviewopts($n,$button_id)
if {$val eq $value} {
lappend rargs $pattern
}
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
} else {
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
set val $newviewopts($n,[lindex $opt 0])
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set val [string trim $val]
if {$val ne {}} {
set pfix [string range $pattern 0 end-1]
lappend rargs $pfix$val
}
}
}
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
set rargs [concat $rargs [shellsplit $newviewopts($n,refs)]]
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
return [concat $rargs [shellsplit $newviewopts($n,args)]]
}
proc decode_view_opts {n view_args} {
global known_view_options newviewopts
foreach opt $known_view_options {
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
set id [lindex $opt 0]
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
if {[lindex $opt 1] eq "b"} {
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
# Checkboxes
set val 0
} elseif {[regexp {^r(\d+)$} [lindex $opt 1]]} {
# Radiobuttons
regexp {^(.*_)} $id uselessvar id
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set val 0
} else {
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
# Text fields
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set val {}
}
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
set newviewopts($n,$id) $val
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
}
set oargs [list]
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
set refargs [list]
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
foreach arg $view_args {
if {[regexp -- {^-([0-9]+)$} $arg arg cnt]
&& ![info exists found(limit)]} {
set newviewopts($n,limit) $cnt
set found(limit) 1
continue
}
catch { unset val }
foreach opt $known_view_options {
set id [lindex $opt 0]
if {[info exists found($id)]} continue
foreach pattern [lindex $opt 3] {
if {![string match $pattern $arg]} continue
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
if {[lindex $opt 1] eq "b"} {
# Check buttons
set val 1
} elseif {[regexp {^r(\d+)$} [lindex $opt 1] match num]} {
# Radio buttons
regexp {^(.*_)} $id uselessvar id
set val $num
} else {
# Text input fields
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set size [string length $pattern]
set val [string range $arg [expr {$size-1}] end]
}
set newviewopts($n,$id) $val
set found($id) 1
break
}
if {[info exists val]} break
}
if {[info exists val]} continue
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
if {[regexp {^-} $arg]} {
lappend oargs $arg
} else {
lappend refargs $arg
}
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
}
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
set newviewopts($n,refs) [shellarglist $refargs]
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set newviewopts($n,args) [shellarglist $oargs]
}
gitk: Add accelerators to frequently used menu commands This commit documents keyboard accelerators used for menu commands in the menu, as it is usually done, and adds some more, e.g. F4 to invoke Edit View (or New View if the current view is the un-editable "All files" view). The changes include a workaround for handling Shift-F4 on systems where XKB binds special XF86_Switch_VT_* symbols to Ctrl-Alt-F* combinations. Tk often receives these codes when Shift-F* is pressed, so it is necessary to bind the relevant actions to them as well. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 11:00:45 +01:00
proc edit_or_newview {} {
global curview
if {$curview > 0} {
editview
} else {
newview 0
}
}
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
proc editview {} {
global curview
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
global viewname viewperm newviewname newviewopts
global viewargs viewargscmd
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
set top .gitkvedit-$curview
if {[winfo exists $top]} {
raise $top
return
}
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set newviewname($curview) $viewname($curview)
set newviewopts($curview,perm) $viewperm($curview)
set newviewopts($curview,cmd) $viewargscmd($curview)
decode_view_opts $curview $viewargs($curview)
gitk: Mark some more strings for translation Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-30 21:17:25 +02:00
vieweditor $top $curview "[mc "Gitk: edit view"] $viewname($curview)"
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
}
proc vieweditor {top n title} {
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
global newviewname newviewopts viewfiles bgcolor
global known_view_options
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
toplevel $top
gitk: Add another string to translation Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-05-23 11:48:25 +02:00
wm title $top [concat $title [mc "-- criteria for selecting revisions"]]
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $top .
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
# View name
frame $top.nfr
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
label $top.nl -text [mc "View Name:"]
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
entry $top.name -width 20 -textvariable newviewname($n)
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
pack $top.nfr -in $top -fill x -pady 5 -padx 3
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
pack $top.nl -in $top.nfr -side left -padx {0 5}
pack $top.name -in $top.nfr -side left -padx {0 25}
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
# View options
set cframe $top.nfr
set cexpand 0
set cnt 0
foreach opt $known_view_options {
set id [lindex $opt 0]
set type [lindex $opt 1]
set flags [lindex $opt 2]
set title [eval [lindex $opt 4]]
set lxpad 0
if {$flags eq "+" || $flags eq "*"} {
set cframe $top.fr$cnt
incr cnt
frame $cframe
pack $cframe -in $top -fill x -pady 3 -padx 3
set cexpand [expr {$flags eq "*"}]
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
} elseif {$flags eq ".." || $flags eq "*."} {
set cframe $top.fr$cnt
incr cnt
frame $cframe
pack $cframe -in $top -fill x -pady 3 -padx [list 15 3]
set cexpand [expr {$flags eq "*."}]
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
} else {
set lxpad 5
}
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
if {$type eq "l"} {
label $cframe.l_$id -text $title
pack $cframe.l_$id -in $cframe -side left -pady [list 3 0] -anchor w
} elseif {$type eq "b"} {
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
checkbutton $cframe.c_$id -text $title -variable newviewopts($n,$id)
pack $cframe.c_$id -in $cframe -side left \
-padx [list $lxpad 0] -expand $cexpand -anchor w
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
} elseif {[regexp {^r(\d+)$} $type type sz]} {
regexp {^(.*_)} $id uselessvar button_id
radiobutton $cframe.c_$id -text $title -variable newviewopts($n,$button_id) -value $sz
pack $cframe.c_$id -in $cframe -side left \
-padx [list $lxpad 0] -expand $cexpand -anchor w
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
} elseif {[regexp {^t(\d+)$} $type type sz]} {
message $cframe.l_$id -aspect 1500 -text $title
entry $cframe.e_$id -width $sz -background $bgcolor \
-textvariable newviewopts($n,$id)
pack $cframe.l_$id -in $cframe -side left -padx [list $lxpad 0]
pack $cframe.e_$id -in $cframe -side left -expand 1 -fill x
} elseif {[regexp {^t(\d+)=$} $type type sz]} {
message $cframe.l_$id -aspect 1500 -text $title
entry $cframe.e_$id -width $sz -background $bgcolor \
-textvariable newviewopts($n,$id)
pack $cframe.l_$id -in $cframe -side top -pady [list 3 0] -anchor w
pack $cframe.e_$id -in $cframe -side top -fill x
gitk: Make more options easily accessible from Edit View dialog Commit 218a900bd8efd0d49f8a0d9491aa4786a998d4f4 added a number of new individual fields for the Edit View dialog to make them more accessible to end users, while still allowing all options to be specified in the "arguments to git log" field. This extends the dialog further, to include refs, author, committer, commit message, and patch contents. As before everything still remains accessible from the "arguments to git log" input field. Additionally, this provides hints for the format of the various input fields (for example, listing some sample date strings in different formats), and puts related query items into subsections to make it easier to digest the number of options that exist. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 18:57:46 +01:00
} elseif {$type eq "path"} {
message $top.l -aspect 1500 -text $title
pack $top.l -in $top -side top -pady [list 3 0] -anchor w -padx 3
text $top.t -width 40 -height 5 -background $bgcolor -font uifont
if {[info exists viewfiles($n)]} {
foreach f $viewfiles($n) {
$top.t insert end $f
$top.t insert end "\n"
}
$top.t delete {end - 1c} end
$top.t mark set insert 0.0
}
pack $top.t -in $top -side top -pady [list 0 5] -fill both -expand 1 -padx 3
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
}
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
frame $top.buts
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
button $top.buts.ok -text [mc "OK"] -command [list newviewok $top $n]
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
button $top.buts.apply -text [mc "Apply (F5)"] -command [list newviewok $top $n 1]
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
button $top.buts.can -text [mc "Cancel"] -command [list destroy $top]
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
bind $top <Control-Return> [list newviewok $top $n]
bind $top <F5> [list newviewok $top $n 1]
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Escape> [list destroy $top]
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
grid $top.buts.ok $top.buts.apply $top.buts.can
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
grid columnconfigure $top.buts 2 -weight 1 -uniform a
pack $top.buts -in $top -side top -fill x
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
focus $top.t
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
proc doviewmenu {m first cmd op argv} {
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
set nmenu [$m index end]
for {set i $first} {$i <= $nmenu} {incr i} {
if {[$m entrycget $i -command] eq $cmd} {
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
eval $m $op $i $argv
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
break
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
}
}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
proc allviewmenus {n op args} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
# global viewhlmenu
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
gitk: Fix enabling/disabling of menu items on Mac OS X It seems that under Mac OS X, the menus get some extra entries (or possibly fewer entries), leading to references to entries by an absolute number being off. This leads to an error when invoking gitk --all under Mac OS X, because the "Edit view" and "Delete view" entries aren't were gitk expects them, and so enabling them gives an error. This changes the code so it refers to menu entries by their content, which should solve the problem. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-23 11:06:16 +01:00
doviewmenu .bar.view 5 [list showview $n] $op $args
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
# doviewmenu $viewhlmenu 1 [list addvhighlight $n] $op $args
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
}
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
proc newviewok {top n {apply 0}} {
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
global nextviewnum newviewperm newviewname newishighlight
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
global viewname viewfiles viewperm selectedview curview
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
global viewargs viewargscmd newviewopts viewhlmenu
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
if {[catch {
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set newargs [encode_view_opts $n]
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
} err]} {
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
error_popup "[mc "Error in commit selection arguments:"] $err" $top
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
return
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set files {}
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
foreach f [split [$top.t get 0.0 end] "\n"] {
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set ft [string trim $f]
if {$ft ne {}} {
lappend files $ft
}
}
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
if {![info exists viewfiles($n)]} {
# creating a new view
incr nextviewnum
set viewname($n) $newviewname($n)
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set viewperm($n) $newviewopts($n,perm)
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
set viewfiles($n) $files
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
set viewargs($n) $newargs
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set viewargscmd($n) $newviewopts($n,cmd)
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
addviewmenu $n
if {!$newishighlight} {
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
run showview $n
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
} else {
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
run addvhighlight $n
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
} else {
# editing an existing view
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set viewperm($n) $newviewopts($n,perm)
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
if {$newviewname($n) ne $viewname($n)} {
set viewname($n) $newviewname($n)
gitk: Fix enabling/disabling of menu items on Mac OS X It seems that under Mac OS X, the menus get some extra entries (or possibly fewer entries), leading to references to entries by an absolute number being off. This leads to an error when invoking gitk --all under Mac OS X, because the "Edit view" and "Delete view" entries aren't were gitk expects them, and so enabling them gives an error. This changes the code so it refers to menu entries by their content, which should solve the problem. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-11-23 11:06:16 +01:00
doviewmenu .bar.view 5 [list showview $n] \
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
entryconf [list -label $viewname($n)]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
# doviewmenu $viewhlmenu 1 [list addvhighlight $n] \
# entryconf [list -label $viewname($n) -value $viewname($n)]
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
}
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
if {$files ne $viewfiles($n) || $newargs ne $viewargs($n) || \
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
$newviewopts($n,cmd) ne $viewargscmd($n)} {
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
set viewfiles($n) $files
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
set viewargs($n) $newargs
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
set viewargscmd($n) $newviewopts($n,cmd)
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
if {$curview == $n} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
run reloadcommits
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
}
}
}
gitk: Implement a user-friendly Edit View dialog Originally gitk required the user to specify all limiting options manually in the same field with the list of commits. It is rather unfriendly for new users, who may not know which options can be used, or, indeed, that it is possible to specify them at all. This commit modifies the dialog to present the most useful options as individual fields. Note that options that may be useful to an extent, but produce a severely broken view, are deliberately not included. It is still possible to specify options in the commit list field, but when the dialog is reopened, they will be extracted into their own separate fields. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:48 +01:00
if {$apply} return
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
catch {destroy $top}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
}
proc delview {} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global curview viewperm hlview selectedhlview
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
if {$curview == 0} return
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
if {[info exists hlview] && $hlview == $curview} {
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set selectedhlview [mc "None"]
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
unset hlview
}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
allviewmenus $curview delete
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
set viewperm($curview) 0
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
showview 0
}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
proc addviewmenu {n} {
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
global viewname viewhlmenu
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
.bar.view add radiobutton -label $viewname($n) \
-command [list showview $n] -variable selectedview -value $n
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
#$viewhlmenu add radiobutton -label $viewname($n) \
# -command [list addvhighlight $n] -variable selectedhlview
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
proc showview {n} {
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
global curview cached_commitrow ordertok
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
global displayorder parentlist rowidlist rowisopt rowfinal
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global colormap rowtextx nextcolor canvxmax
global numcommits viewcomplete
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
global selectedline currentid canv canvy0
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
global treediffs
gitk: Select head of current branch by default Instead of selecting the first commit that appears, this makes gitk select the currently checked out head, if the user hasn't explicitly selected some other commit by the time it appears. If the head hasn't appeared by the time the graph is complete, then we select the first real commit. This applies both for graph updates and when the graph is being read in initially. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-13 07:26:30 +01:00
global pending_select mainheadid
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global commitidx
gitk: Select head of current branch by default Instead of selecting the first commit that appears, this makes gitk select the currently checked out head, if the user hasn't explicitly selected some other commit by the time it appears. If the head hasn't appeared by the time the graph is complete, then we select the first real commit. This applies both for graph updates and when the graph is being read in initially. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-13 07:26:30 +01:00
global selectedview
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
global hlview selectedhlview commitinterest
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
if {$n == $curview} return
set selid {}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set ymax [lindex [$canv cget -scrollregion] 3]
set span [$canv yview]
set ytop [expr {[lindex $span 0] * $ymax}]
set ybot [expr {[lindex $span 1] * $ymax}]
set yscreen [expr {($ybot - $ytop) / 2}]
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline ne {}} {
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set selid $currentid
set y [yc $selectedline]
if {$ytop < $y && $y < $ybot} {
set yscreen [expr {$y - $ytop}]
}
gitk: Improve the behaviour of the initial selection It used to be that if you clicked on a line while gitk was still drawing stuff, it would immediately re-select the first line of the display. This fixes that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:51:08 +02:00
} elseif {[info exists pending_select]} {
set selid $pending_select
unset pending_select
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
}
unselectline
gitk: Fix various bugs in the view support - don't re-read refs when switching views, it's too slow; just do it if the user did File->Update - make the view menu use the uifont - if we have a graph line selected, unselect it before changing the view - if a row is selected and appears in the new view, but we have to read in the new view, select that row when we come across it - if no row was previously selected, or if we don't find the previously selected row in the new view, select the first row Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-06 13:22:52 +02:00
normalline
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
catch {unset treediffs}
clear_display
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
if {[info exists hlview] && $hlview == $n} {
unset hlview
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set selectedhlview [mc "None"]
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
catch {unset commitinterest}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
catch {unset cached_commitrow}
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
catch {unset ordertok}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set curview $n
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
set selectedview $n
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
.bar.view entryconf [mca "Edit view..."] -state [expr {$n == 0? "disabled": "normal"}]
.bar.view entryconf [mca "Delete view"] -state [expr {$n == 0? "disabled": "normal"}]
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
gitk: Fix bug causing incorrect ref list contents when switching view If the view we're switching to hadn't been read in, we hit an early return in showview which meant we didn't update the ref list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 14:03:07 +02:00
run refill_reflist
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![info exists viewcomplete($n)]} {
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
getcommits $selid
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
return
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set displayorder {}
set parentlist {}
set rowidlist {}
set rowisopt {}
set rowfinal {}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
set numcommits $commitidx($n)
gitk: Don't reread git-rev-list output from scratch on view switch Previously, if we switched away from a view before we had finished reading the git-rev-list output for it and laying out the graph, we would discard the partially-laid-out graph and reread it from scratch if we switched back to the view. With this, we preserve the state of the partially-laid-out graph in viewdata($view) and restore it if we switch back. The pipe to git-rev-list remains open but we just don't read from it any more until we switch back to that view. This also makes linesegends a list rather than an array, which turns out to be slightly faster, as well as being easier to save and restore. The `update' menu item now kills the git-rev-list process if there is one still running when we do the update. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-17 01:56:02 +02:00
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
catch {unset colormap}
catch {unset rowtextx}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
set nextcolor 0
set canvxmax [$canv cget -width]
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set curview $n
set row 0
setcanvscroll
set yf 0
gitk: Improve the behaviour of the initial selection It used to be that if you clicked on a line while gitk was still drawing stuff, it would immediately re-select the first line of the display. This fixes that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:51:08 +02:00
set row {}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$selid ne {} && [commitinview $selid $n]} {
set row [rowofcommit $selid]
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
# try to get the selected row in the same position on the screen
set ymax [lindex [$canv cget -scrollregion] 3]
set ytop [expr {[yc $row] - $yscreen}]
if {$ytop < 0} {
set ytop 0
}
set yf [expr {$ytop * 1.0 / $ymax}]
}
allcanvs yview moveto $yf
drawvisible
gitk: Improve the behaviour of the initial selection It used to be that if you clicked on a line while gitk was still drawing stuff, it would immediately re-select the first line of the display. This fixes that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:51:08 +02:00
if {$row ne {}} {
selectline $row 0
gitk: Select head of current branch by default Instead of selecting the first commit that appears, this makes gitk select the currently checked out head, if the user hasn't explicitly selected some other commit by the time it appears. If the head hasn't appeared by the time the graph is complete, then we select the first real commit. This applies both for graph updates and when the graph is being read in initially. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-13 07:26:30 +01:00
} elseif {!$viewcomplete($n)} {
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
reset_pending_select $selid
gitk: Improve the behaviour of the initial selection It used to be that if you clicked on a line while gitk was still drawing stuff, it would immediately re-select the first line of the display. This fixes that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:51:08 +02:00
} else {
gitk: Fallback to selecting the head commit upon load Try selecting the head, if the previously selected commit is not available in the new view. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:15:54 +02:00
reset_pending_select {}
if {[commitinview $pending_select $curview]} {
selectline [rowofcommit $pending_select] 1
} else {
set row [first_real_row]
if {$row < $numcommits} {
selectline $row 0
}
gitk: Improve the behaviour of the initial selection It used to be that if you clicked on a line while gitk was still drawing stuff, it would immediately re-select the first line of the display. This fixes that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:51:08 +02:00
}
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {!$viewcomplete($n)} {
if {$numcommits == 0} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
show_status [mc "Reading commits..."]
gitk: add menu item for editing the current view This allows the user to change the name of the view, whether it is permanent, and the list of files/directories for the view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 13:21:10 +02:00
}
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
} elseif {$numcommits == 0} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
show_status [mc "No commits selected"]
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
# Stuff relating to the highlighting facility
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
proc ishighlighted {id} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
global vhighlights fhighlights nhighlights rhighlights
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {[info exists nhighlights($id)] && $nhighlights($id) > 0} {
return $nhighlights($id)
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {[info exists vhighlights($id)] && $vhighlights($id) > 0} {
return $vhighlights($id)
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {[info exists fhighlights($id)] && $fhighlights($id) > 0} {
return $fhighlights($id)
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {[info exists rhighlights($id)] && $rhighlights($id) > 0} {
return $rhighlights($id)
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
return 0
}
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
proc bolden {id font} {
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
global canv linehtag currentid boldids need_redisplay markedid
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
gitk: Fix linehtag undefined error with file highlighting Occasionally gitk will throw a Tcl error complaining that linehtag(n) is undefined when. It happens when the commit list is still growing (e.g. when updating the commit list) and gitk is set to highlight commits that affect certain file(s). What happens is that the changes to the commit list set need_redisplay to indicate that the display needs to be redrawn. That causes the next call to drawcommits to call clear_display, which unsets iddrawn and thus ensures that readfhighlight won't call bolden on any rows that have moved. However, it is possible for readfhighlight to be called after the commit list has changed but before drawcommits has run, meaning that readfhighlight will potentially think that rows have been drawn when they haven't, because of the change in the id -> row mapping (and the fact that iddrawn is indexed by id but line[hnd]tag are indexed by row number). This fixes it (and also optimizes things a little) by making bolden and bolden_name check need_redisplay before doing anything. If need_redisplay is set, then there is no point doing anything because the whole display is about to get cleared and redrawn, and it avoids looking up line[hn]tag using stale row numbers. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 12:39:00 +01:00
# need_redisplay = 1 means the display is stale and about to be redrawn
if {$need_redisplay} return
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
lappend boldids $id
$canv itemconf $linehtag($id) -font $font
if {[info exists currentid] && $id eq $currentid} {
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
$canv delete secsel
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set t [eval $canv create rect [$canv bbox $linehtag($id)] \
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
-outline {{}} -tags secsel \
-fill [$canv cget -selectbackground]]
$canv lower $t
}
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
if {[info exists markedid] && $id eq $markedid} {
make_idmark $id
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
proc bolden_name {id font} {
global canv2 linentag currentid boldnameids need_redisplay
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
gitk: Fix linehtag undefined error with file highlighting Occasionally gitk will throw a Tcl error complaining that linehtag(n) is undefined when. It happens when the commit list is still growing (e.g. when updating the commit list) and gitk is set to highlight commits that affect certain file(s). What happens is that the changes to the commit list set need_redisplay to indicate that the display needs to be redrawn. That causes the next call to drawcommits to call clear_display, which unsets iddrawn and thus ensures that readfhighlight won't call bolden on any rows that have moved. However, it is possible for readfhighlight to be called after the commit list has changed but before drawcommits has run, meaning that readfhighlight will potentially think that rows have been drawn when they haven't, because of the change in the id -> row mapping (and the fact that iddrawn is indexed by id but line[hnd]tag are indexed by row number). This fixes it (and also optimizes things a little) by making bolden and bolden_name check need_redisplay before doing anything. If need_redisplay is set, then there is no point doing anything because the whole display is about to get cleared and redrawn, and it avoids looking up line[hn]tag using stale row numbers. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 12:39:00 +01:00
if {$need_redisplay} return
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
lappend boldnameids $id
$canv2 itemconf $linentag($id) -font $font
if {[info exists currentid] && $id eq $currentid} {
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
$canv2 delete secsel
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set t [eval $canv2 create rect [$canv2 bbox $linentag($id)] \
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
-outline {{}} -tags secsel \
-fill [$canv2 cget -selectbackground]]
$canv2 lower $t
}
}
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
proc unbolden {} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
global boldids
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
set stillbold {}
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
foreach id $boldids {
if {![ishighlighted $id]} {
bolden $id mainfont
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
} else {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
lappend stillbold $id
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
}
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set boldids $stillbold
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
proc addvhighlight {n} {
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
global hlview viewcomplete curview vhl_done commitidx
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
if {[info exists hlview]} {
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
delvhighlight
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
set hlview $n
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$n != $curview && ![info exists viewcomplete($n)]} {
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
start_rev_list $n
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
set vhl_done $commitidx($hlview)
if {$vhl_done > 0} {
drawvisible
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
proc delvhighlight {} {
global hlview vhighlights
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
if {![info exists hlview]} return
unset hlview
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
catch {unset vhighlights}
unbolden
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
proc vhighlightmore {} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global hlview vhl_done commitidx vhighlights curview
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
set max $commitidx($hlview)
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
set vr [visiblerows]
set r0 [lindex $vr 0]
set r1 [lindex $vr 1]
for {set i $vhl_done} {$i < $max} {incr i} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set id [commitonrow $i $hlview]
if {[commitinview $id $curview]} {
set row [rowofcommit $id]
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
if {$r0 <= $row && $row <= $r1} {
if {![highlighted $row]} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
bolden $id mainfontbold
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set vhighlights($id) 1
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
}
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
set vhl_done $max
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
return 0
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
proc askvhighlight {row id} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global hlview vhighlights iddrawn
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $id $hlview]} {
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {[info exists iddrawn($id)] && ![ishighlighted $id]} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
bolden $id mainfontbold
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set vhighlights($id) 1
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
} else {
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set vhighlights($id) 0
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
proc hfiles_change {} {
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
global highlight_files filehighlight fhighlights fh_serial
gitk: Highlight only when search type is "containing:". When the search type is "touching paths" or "adding/removing string", it's not very useful to highlight instances of the search string in the commit message, headline or author name, so this disables the highlighting in those cases. This was suggested by Mark Burton <markb@ordern.com>, but the implementation is different to his patch, which tested $gdttype at each place where $markingmatches was tested. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-01 23:02:46 +01:00
global highlight_paths
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
if {[info exists filehighlight]} {
# delete previous highlights
catch {close $filehighlight}
unset filehighlight
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
catch {unset fhighlights}
unbolden
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
unhighlight_filelist
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
set highlight_paths {}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
after cancel do_file_hl $fh_serial
incr fh_serial
if {$highlight_files ne {}} {
after 300 do_file_hl $fh_serial
}
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
proc gdttype_change {name ix op} {
global gdttype highlight_files findstring findpattern
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
stopfinding
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
if {$findstring ne {}} {
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$gdttype eq [mc "containing:"]} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
if {$highlight_files ne {}} {
set highlight_files {}
hfiles_change
}
findcom_change
} else {
if {$findpattern ne {}} {
set findpattern {}
findcom_change
}
set highlight_files $findstring
hfiles_change
}
drawvisible
}
# enable/disable findtype/findloc menus too
}
proc find_change {name ix op} {
global gdttype findstring highlight_files
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
stopfinding
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$gdttype eq [mc "containing:"]} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
findcom_change
} else {
if {$highlight_files ne $findstring} {
set highlight_files $findstring
hfiles_change
}
}
drawvisible
}
gitk: Fix bug causing Tcl error when changing find match type When changing the selector for Exact/IgnCase/Regexp, we were getting a Tcl error. This fixes it. It also adds a workaround for a bug in alpha versions of Tk8.5 where wordprocessor-style tabs don't seem to work properly around column 1. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:19:24 +02:00
proc findcom_change args {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
global nhighlights boldnameids
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
global findpattern findtype findstring gdttype
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
stopfinding
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
# delete previous highlights, if any
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
foreach id $boldnameids {
bolden_name $id mainfont
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
}
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set boldnameids {}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
catch {unset nhighlights}
unbolden
unmarkmatches
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$gdttype ne [mc "containing:"] || $findstring eq {}} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
set findpattern {}
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
} elseif {$findtype eq [mc "Regexp"]} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
set findpattern $findstring
} else {
set e [string map {"*" "\\*" "?" "\\?" "\[" "\\\[" "\\" "\\\\"} \
$findstring]
set findpattern "*$e*"
}
}
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
proc makepatterns {l} {
set ret {}
foreach e $l {
set ee [string map {"*" "\\*" "?" "\\?" "\[" "\\\[" "\\" "\\\\"} $e]
if {[string index $ee end] eq "/"} {
lappend ret "$ee*"
} else {
lappend ret $ee
lappend ret "$ee/*"
}
}
return $ret
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
proc do_file_hl {serial} {
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
global highlight_files filehighlight highlight_paths gdttype fhl_list
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$gdttype eq [mc "touching paths:"]} {
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
if {[catch {set paths [shellsplit $highlight_files]}]} return
set highlight_paths [makepatterns $paths]
highlight_filelist
set gdtargs [concat -- $paths]
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
} elseif {$gdttype eq [mc "adding/removing string:"]} {
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
set gdtargs [list "-S$highlight_files"]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
} else {
# must be "containing:", i.e. we're searching commit info
return
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
}
[PATCH] prefer "git COMMAND" over "git-COMMAND" in gitk Preferring git _space_ COMMAND over git _dash_ COMMAND allows the user to have only git and gitk in their path. e.g. when git and gitk are symbolic links in a personal bin directory to the real git and gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-20 00:00:37 +01:00
set cmd [concat | git diff-tree -r -s --stdin $gdtargs]
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
set filehighlight [open $cmd r+]
fconfigure $filehighlight -blocking 0
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
filerun $filehighlight readfhighlight
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
set fhl_list {}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
drawvisible
flushhighlights
}
proc flushhighlights {} {
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
global filehighlight fhl_list
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
if {[info exists filehighlight]} {
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
lappend fhl_list {}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
puts $filehighlight ""
flush $filehighlight
}
}
proc askfilehighlight {row id} {
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
global filehighlight fhighlights fhl_list
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
lappend fhl_list $id
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set fhighlights($id) -1
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
puts $filehighlight $id
}
proc readfhighlight {} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global filehighlight fhighlights curview iddrawn
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
global fhl_list find_dirn
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
if {![info exists filehighlight]} {
return 0
}
set nr 0
while {[incr nr] <= 100 && [gets $filehighlight line] >= 0} {
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
set line [string trim $line]
set i [lsearch -exact $fhl_list $line]
if {$i < 0} continue
for {set j 0} {$j < $i} {incr j} {
set id [lindex $fhl_list $j]
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set fhighlights($id) 0
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
set fhl_list [lrange $fhl_list [expr {$i+1}] end]
if {$line eq {}} continue
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![commitinview $line $curview]} continue
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {[info exists iddrawn($line)] && ![ishighlighted $line]} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
bolden $line mainfontbold
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set fhighlights($line) 1
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
if {[eof $filehighlight]} {
# strange...
[PATCH] prefer "git COMMAND" over "git-COMMAND" in gitk Preferring git _space_ COMMAND over git _dash_ COMMAND allows the user to have only git and gitk in their path. e.g. when git and gitk are symbolic links in a personal bin directory to the real git and gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-20 00:00:37 +01:00
puts "oops, git diff-tree died"
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
catch {close $filehighlight}
unset filehighlight
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
if {[info exists find_dirn]} {
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
run findmore
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
return 1
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
proc doesmatch {f} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
global findtype findpattern
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$findtype eq [mc "Regexp"]} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
return [regexp $findpattern $f]
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
} elseif {$findtype eq [mc "IgnCase"]} {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
return [string match -nocase $findpattern $f]
} else {
return [string match $findpattern $f]
}
}
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
proc askfindhighlight {row id} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
global nhighlights commitinfo iddrawn
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
global findloc
global markingmatches
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
if {![info exists commitinfo($id)]} {
getcommit $id
}
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
set info $commitinfo($id)
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
set isbold 0
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set fldtypes [list [mc Headline] [mc Author] [mc Date] [mc Committer] [mc CDate] [mc Comments]]
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
foreach f $info ty $fldtypes {
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {($findloc eq [mc "All fields"] || $findloc eq $ty) &&
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
[doesmatch $f]} {
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$ty eq [mc "Author"]} {
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
set isbold 2
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
break
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set isbold 1
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
if {$isbold && [info exists iddrawn($id)]} {
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {![ishighlighted $id]} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
bolden $id mainfontbold
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
if {$isbold > 1} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
bolden_name $id mainfontbold
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
if {$markingmatches} {
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
markrowmatches $row $id
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set nhighlights($id) $isbold
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
proc markrowmatches {row id} {
global canv canv2 linehtag linentag commitinfo findloc
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
set headline [lindex $commitinfo($id) 0]
set author [lindex $commitinfo($id) 1]
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
$canv delete match$row
$canv2 delete match$row
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$findloc eq [mc "All fields"] || $findloc eq [mc "Headline"]} {
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
set m [findmatches $headline]
if {$m ne {}} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
markmatches $canv $row $headline $linehtag($id) $m \
[$canv itemcget $linehtag($id) -font] $row
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
}
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$findloc eq [mc "All fields"] || $findloc eq [mc "Author"]} {
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
set m [findmatches $author]
if {$m ne {}} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
markmatches $canv2 $row $author $linentag($id) $m \
[$canv2 itemcget $linentag($id) -font] $row
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
}
}
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
proc vrel_change {name ix op} {
global highlight_related
rhighlight_none
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$highlight_related ne [mc "None"]} {
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
run drawvisible
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
}
}
# prepare for testing whether commits are descendents or ancestors of a
proc rhighlight_sel {a} {
global descendent desc_todo ancestor anc_todo
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
global highlight_related
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
catch {unset descendent}
set desc_todo [list $a]
catch {unset ancestor}
set anc_todo [list $a]
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$highlight_related ne [mc "None"]} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
rhighlight_none
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
run drawvisible
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
}
}
proc rhighlight_none {} {
global rhighlights
gitk: Add a goto next/previous highlighted commit function This is invoked by shift-down/shift-up. It relies on a patch to git-diff-tree that has recently gone into the git repository, commit ID e0c97ca6 (without this it may just sit there doing waiting for git-diff-tree when looking for the next/previous highlight). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-30 13:33:07 +02:00
catch {unset rhighlights}
unbolden
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
}
proc is_descendent {a} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global curview children descendent desc_todo
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
set v $curview
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set la [rowofcommit $a]
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
set todo $desc_todo
set leftover {}
set done 0
for {set i 0} {$i < [llength $todo]} {incr i} {
set do [lindex $todo $i]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[rowofcommit $do] < $la} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
lappend leftover $do
continue
}
foreach nk $children($v,$do) {
if {![info exists descendent($nk)]} {
set descendent($nk) 1
lappend todo $nk
if {$nk eq $a} {
set done 1
}
}
}
if {$done} {
set desc_todo [concat $leftover [lrange $todo [expr {$i+1}] end]]
return
}
}
set descendent($a) 0
set desc_todo $leftover
}
proc is_ancestor {a} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global curview parents ancestor anc_todo
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
set v $curview
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set la [rowofcommit $a]
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
set todo $anc_todo
set leftover {}
set done 0
for {set i 0} {$i < [llength $todo]} {incr i} {
set do [lindex $todo $i]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![commitinview $do $v] || [rowofcommit $do] > $la} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
lappend leftover $do
continue
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
foreach np $parents($v,$do) {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
if {![info exists ancestor($np)]} {
set ancestor($np) 1
lappend todo $np
if {$np eq $a} {
set done 1
}
}
}
if {$done} {
set anc_todo [concat $leftover [lrange $todo [expr {$i+1}] end]]
return
}
}
set ancestor($a) 0
set anc_todo $leftover
}
proc askrelhighlight {row id} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
global descendent highlight_related iddrawn rhighlights
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
global selectedline ancestor
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {}} return
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
set isbold 0
gitk: Fix typo in user message. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-09 22:23:18 +01:00
if {$highlight_related eq [mc "Descendant"] ||
$highlight_related eq [mc "Not descendant"]} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
if {![info exists descendent($id)]} {
is_descendent $id
}
gitk: Fix typo in user message. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-09 22:23:18 +01:00
if {$descendent($id) == ($highlight_related eq [mc "Descendant"])} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
set isbold 1
}
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
} elseif {$highlight_related eq [mc "Ancestor"] ||
$highlight_related eq [mc "Not ancestor"]} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
if {![info exists ancestor($id)]} {
is_ancestor $id
}
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$ancestor($id) == ($highlight_related eq [mc "Ancestor"])} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
set isbold 1
}
}
if {[info exists iddrawn($id)]} {
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {$isbold && ![ishighlighted $id]} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
bolden $id mainfontbold
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
}
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set rhighlights($id) $isbold
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
# Graph layout functions
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
proc shortids {ids} {
set res {}
foreach id $ids {
if {[llength $id] > 1} {
lappend res [shortids $id]
} elseif {[regexp {^[0-9a-f]{40}$} $id]} {
lappend res [string range $id 0 7]
} else {
lappend res $id
}
}
return $res
}
proc ntimes {n o} {
set ret {}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set o [list $o]
for {set mask 1} {$mask <= $n} {incr mask $mask} {
if {($n & $mask) != 0} {
set ret [concat $ret $o]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set o [concat $o $o]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
return $ret
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
proc ordertoken {id} {
global ordertok curview varcid varcstart varctok curview parents children
global nullid nullid2
if {[info exists ordertok($id)]} {
return $ordertok($id)
}
set origid $id
set todo {}
while {1} {
if {[info exists varcid($curview,$id)]} {
set a $varcid($curview,$id)
set p [lindex $varcstart($curview) $a]
} else {
set p [lindex $children($curview,$id) 0]
}
if {[info exists ordertok($p)]} {
set tok $ordertok($p)
break
}
gitk: Fix potential bug with fake commit IDs in renumbervarc When a fake row is added, we add its (fake) ID to the children list for its (fake) parent. If renumbervarc were to then renumber the parent it would incorrectly use the fake child. This avoids the problem by adding a last_real_child procedure which won't return a fake ID, and using it in renumbervarc. For symmetry this also adds a first_real_child procedure and uses it in ordertoken. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 03:54:58 +01:00
set id [first_real_child $curview,$p]
if {$id eq {}} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
# it's a root
gitk: Select something appropriate on cherry-pick, branch reset and checkout This makes gitk select the new commit when cherry-picking, and select the new checked-out head when resetting or checking out a branch. This feels more natural because the user is usually more interested in that commit now than whatever was selected before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-15 12:16:32 +01:00
set tok [lindex $varctok($curview) $varcid($curview,$p)]
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
break
}
if {[llength $parents($curview,$id)] == 1} {
lappend todo [list $p {}]
} else {
set j [lsearch -exact $parents($curview,$id) $p]
if {$j < 0} {
puts "oops didn't find [shortids $p] in parents of [shortids $id]"
}
lappend todo [list $p [strrep $j]]
}
}
for {set i [llength $todo]} {[incr i -1] >= 0} {} {
set p [lindex $todo $i 0]
append tok [lindex $todo $i 1]
set ordertok($p) $tok
}
set ordertok($origid) $tok
return $tok
}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
# Work out where id should go in idlist so that order-token
# values increase from left to right
proc idcol {idlist id {i 0}} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
set t [ordertoken $id]
gitk: Fix more bugs resulting in Tcl "no such element in array" errors First, update_arcrows was being overly aggressive in trimming displayorder, resulting in calls to rowofcommit sometimes trimming off commits that layoutrows had asked for in make_disporder and was relying on having present. This adds a vrowmod($view) variable that lets update_arcrows be more precise in trimming off the invalid bits of displayorder (and it also simplifies the check in make_disporder). This modifies modify_arc and its callers so that vrowmod($view) is updated appropriately. Secondly, we were sometimes calling idcol with $i==-1, which resulted in a call to ordertoken with the null string. This fixes it by forcing $i to 0 if it is less than zero. This also fixes a possible infinite recursion with rowofcommit and update_arcrows calling each other ad infinitum. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-12 08:13:51 +01:00
if {$i < 0} {
set i 0
}
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
if {$i >= [llength $idlist] || $t < [ordertoken [lindex $idlist $i]]} {
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
if {$i > [llength $idlist]} {
set i [llength $idlist]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
while {[incr i -1] >= 0 && $t < [ordertoken [lindex $idlist $i]]} {}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
incr i
} else {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
if {$t > [ordertoken [lindex $idlist $i]]} {
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
while {[incr i] < [llength $idlist] &&
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
$t >= [ordertoken [lindex $idlist $i]]} {}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
return $i
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
proc initlayout {} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global rowidlist rowisopt rowfinal displayorder parentlist
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
global numcommits canvxmax canv
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
global nextcolor
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
global colormap rowtextx
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
set numcommits 0
set displayorder {}
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
set parentlist {}
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
set nextcolor 0
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set rowidlist {}
set rowisopt {}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
set rowfinal {}
gitk: Allow top panes to scroll horizontally with mouse button 2 Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 00:55:11 +02:00
set canvxmax [$canv cget -width]
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
catch {unset colormap}
catch {unset rowtextx}
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
setcanvscroll
gitk: Allow top panes to scroll horizontally with mouse button 2 Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 00:55:11 +02:00
}
proc setcanvscroll {} {
global canv canv2 canv3 numcommits linespc canvxmax canvy0
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
global lastscrollset lastscrollrows
gitk: Allow top panes to scroll horizontally with mouse button 2 Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 00:55:11 +02:00
set ymax [expr {$canvy0 + ($numcommits - 0.5) * $linespc + 2}]
$canv conf -scrollregion [list 0 0 $canvxmax $ymax]
$canv2 conf -scrollregion [list 0 0 0 $ymax]
$canv3 conf -scrollregion [list 0 0 0 $ymax]
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
set lastscrollset [clock clicks -milliseconds]
set lastscrollrows $numcommits
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
proc visiblerows {} {
global canv numcommits linespc
set ymax [lindex [$canv cget -scrollregion] 3]
if {$ymax eq {} || $ymax == 0} return
set f [$canv yview]
set y0 [expr {int([lindex $f 0] * $ymax)}]
set r0 [expr {int(($y0 - 3) / $linespc) - 1}]
if {$r0 < 0} {
set r0 0
}
set y1 [expr {int([lindex $f 1] * $ymax)}]
set r1 [expr {int(($y1 - 3) / $linespc) + 1}]
if {$r1 >= $numcommits} {
set r1 [expr {$numcommits - 1}]
}
return [list $r0 $r1]
}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
proc layoutmore {} {
gitk: Fix bug in assigning row numbers to arcs We weren't setting vtokmod and varcmod in renumbervarc, so after a call to renumbervarc we sometimes weren't reassigning row numbers to all the arcs whose row numbers had changed. This fixes it. This also collapses layoutmore and showstuff into one procedure and gets rid of the phase variable. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-06 10:50:31 +01:00
global commitidx viewcomplete curview
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
global numcommits pending_select curview
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
global lastscrollset lastscrollrows
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
if {$lastscrollrows < 100 || $viewcomplete($curview) ||
[clock clicks -milliseconds] - $lastscrollset > 500} {
gitk: Limit how often we change the canvas scrolling region For some unknown reason, changing the scrolling region on the canvases provokes multiple milliseconds worth of computation in the X server, and this can end up slowing gitk down significantly. This works around the problem by limiting the rate at which we update the scrolling region after the first 100 rows to at most 2 per second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-31 05:00:53 +01:00
setcanvscroll
}
gitk: Make File->Update work properly again If a view is selected it will now just update that view. Also fixed a few other things - if you switch away from a view while gitk is still reading it in, then switch back, gitk will re-read it from scratch. We now re-read the references when switching views. If something was selected before a view change, and we need to read in the new view, we now select the previously-selected commit when we come across it. Fixed a bug in setting of rowrangelist plus a couple of other minor things. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-06 02:18:23 +02:00
if {[info exists pending_select] &&
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
[commitinview $pending_select $curview]} {
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
update
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
selectline [rowofcommit $pending_select] 1
gitk: Make File->Update work properly again If a view is selected it will now just update that view. Also fixed a few other things - if you switch away from a view while gitk is still reading it in, then switch back, gitk will re-read it from scratch. We now re-read the references when switching views. If something was selected before a view change, and we need to read in the new view, we now select the previously-selected commit when we come across it. Fixed a bug in setting of rowrangelist plus a couple of other minor things. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-06 02:18:23 +02:00
}
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
drawvisible
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
# With path limiting, we mightn't get the actual HEAD commit,
# so ask git rev-list what is the first ancestor of HEAD that
# touches a file in the path limit.
proc get_viewmainhead {view} {
global viewmainheadid vfilelimit viewinstances mainheadid
catch {
set rfd [open [concat | git rev-list -1 $mainheadid \
-- $vfilelimit($view)] r]
set j [reg_instance $rfd]
lappend viewinstances($view) $j
fconfigure $rfd -blocking 0
filerun $rfd [list getviewhead $rfd $j $view]
set viewmainheadid($curview) {}
}
}
# git rev-list should give us just 1 line to use as viewmainheadid($view)
proc getviewhead {fd inst view} {
global viewmainheadid commfd curview viewinstances showlocalchanges
set id {}
if {[gets $fd line] < 0} {
if {![eof $fd]} {
return 1
}
} elseif {[string length $line] == 40 && [string is xdigit $line]} {
set id $line
}
set viewmainheadid($view) $id
close $fd
unset commfd($inst)
set i [lsearch -exact $viewinstances($view) $inst]
if {$i >= 0} {
set viewinstances($view) [lreplace $viewinstances($view) $i $i]
}
if {$showlocalchanges && $id ne {} && $view == $curview} {
doshowlocalchanges
}
return 0
}
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
proc doshowlocalchanges {} {
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
global curview viewmainheadid
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
if {$viewmainheadid($curview) eq {}} return
if {[commitinview $viewmainheadid($curview) $curview]} {
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
dodiffindex
gitk: Fix bug in assigning row numbers to arcs We weren't setting vtokmod and varcmod in renumbervarc, so after a call to renumbervarc we sometimes weren't reassigning row numbers to all the arcs whose row numbers had changed. This fixes it. This also collapses layoutmore and showstuff into one procedure and gets rid of the phase variable. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-06 10:50:31 +01:00
} else {
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
interestedin $viewmainheadid($curview) dodiffindex
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
}
proc dohidelocalchanges {} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global nullid nullid2 lserial curview
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $nullid $curview]} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
removefakerow $nullid
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $nullid2 $curview]} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
removefakerow $nullid2
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
incr lserial
}
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
# spawn off a process to do git diff-index --cached HEAD
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
proc dodiffindex {} {
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
global lserial showlocalchanges vfilelimit curview
[PATCH] gitk: Don't show local changes when we there is no work tree Launching gitk on a bare repository or a .git directory would previously show the work tree as having removed all files. We now inhibit showing local changes when gitk is not launched from within a work tree. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-10 11:54:56 +01:00
global isworktree
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
[PATCH] gitk: Don't show local changes when we there is no work tree Launching gitk on a bare repository or a .git directory would previously show the work tree as having removed all files. We now inhibit showing local changes when gitk is not launched from within a work tree. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-10 11:54:56 +01:00
if {!$showlocalchanges || !$isworktree} return
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
incr lserial
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
set cmd "|git diff-index --cached HEAD"
if {$vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
}
set fd [open $cmd r]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
fconfigure $fd -blocking 0
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
set i [reg_instance $fd]
filerun $fd [list readdiffindex $fd $lserial $i]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
proc readdiffindex {fd serial inst} {
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
global viewmainheadid nullid nullid2 curview commitinfo commitdata lserial
global vfilelimit
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set isdiff 1
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
if {[gets $fd line] < 0} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
if {![eof $fd]} {
return 1
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set isdiff 0
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
# we only need to see one line and we don't really care what it says...
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
stop_instance $inst
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
if {$serial != $lserial} {
return 0
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
}
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
# now see if there are any local changes not checked in to the index
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
set cmd "|git diff-files"
if {$vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
}
set fd [open $cmd r]
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
fconfigure $fd -blocking 0
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
set i [reg_instance $fd]
filerun $fd [list readdifffiles $fd $serial $i]
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
if {$isdiff && ![commitinview $nullid2 $curview]} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
# add the line for the changes in the index to the graph
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
set hl [mc "Local changes checked in to index but not committed"]
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set commitinfo($nullid2) [list $hl {} {} {} {} " $hl\n"]
set commitdata($nullid2) "\n $hl\n"
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
if {[commitinview $nullid $curview]} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
removefakerow $nullid
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
}
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
insertfakerow $nullid2 $viewmainheadid($curview)
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
} elseif {!$isdiff && [commitinview $nullid2 $curview]} {
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
if {[commitinview $nullid $curview]} {
removefakerow $nullid
}
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
removefakerow $nullid2
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
}
return 0
}
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
proc readdifffiles {fd serial inst} {
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
global viewmainheadid nullid nullid2 curview
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
global commitinfo commitdata lserial
set isdiff 1
if {[gets $fd line] < 0} {
if {![eof $fd]} {
return 1
}
set isdiff 0
}
# we only need to see one line and we don't really care what it says...
gitk: Arrange to kill diff-files & diff-index on quit Local change analysis can take a noticeable amount of time on large file sets, and produce no output if there are no changes. Register the back-ends in commfd, so that they get properly killed on window close. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-13 14:40:47 +02:00
stop_instance $inst
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
if {$serial != $lserial} {
return 0
}
if {$isdiff && ![commitinview $nullid $curview]} {
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
# add the line for the local diff to the graph
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
set hl [mc "Local uncommitted changes, not checked in to index"]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set commitinfo($nullid) [list $hl {} {} {} {} " $hl\n"]
set commitdata($nullid) "\n $hl\n"
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $nullid2 $curview]} {
set p $nullid2
} else {
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
set p $viewmainheadid($curview)
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
}
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
insertfakerow $nullid $p
gitk: More bug fixes and cleanups * Add/remove fake commits (for local changes) when updating the view even if nothing else has changed. * Get rid of unused getdbg variable. * Get rid of vseeds and uat. * Fix bug where removerow would throw a "no such element in array" error. * Clear out cached highlights when line numbers change. * Make dodiffindex remove the fake commit rows if they currently exist but there are now no local changes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-18 23:35:33 +01:00
} elseif {!$isdiff && [commitinview $nullid $curview]} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
removefakerow $nullid
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
return 0
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Get rid of the rowchk array Instead, when looking for lines that should be terminated with a down arrow, we look at the parents of the commit $downarrowlen + 1 rows before. This gets rid of one more place where we are assuming that all the rows are laid out in order from top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-24 14:16:42 +02:00
proc nextuse {id row} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global curview children
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Get rid of the rowchk array Instead, when looking for lines that should be terminated with a down arrow, we look at the parents of the commit $downarrowlen + 1 rows before. This gets rid of one more place where we are assuming that all the rows are laid out in order from top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-24 14:16:42 +02:00
if {[info exists children($curview,$id)]} {
foreach kid $children($curview,$id) {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![commitinview $kid $curview]} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
return -1
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[rowofcommit $kid] > $row} {
return [rowofcommit $kid]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: Get rid of the rowchk array Instead, when looking for lines that should be terminated with a down arrow, we look at the parents of the commit $downarrowlen + 1 rows before. This gets rid of one more place where we are assuming that all the rows are laid out in order from top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-24 14:16:42 +02:00
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $id $curview]} {
return [rowofcommit $id]
gitk: Get rid of the rowchk array Instead, when looking for lines that should be terminated with a down arrow, we look at the parents of the commit $downarrowlen + 1 rows before. This gets rid of one more place where we are assuming that all the rows are laid out in order from top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-24 14:16:42 +02:00
}
return -1
}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
proc prevuse {id row} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global curview children
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
set ret -1
if {[info exists children($curview,$id)]} {
foreach kid $children($curview,$id) {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![commitinview $kid $curview]} break
if {[rowofcommit $kid] < $row} {
set ret [rowofcommit $kid]
gitk: Fix bug introduced in commit 67a4f1a7 In fixing the "can't unset idinlist" error, I moved the setting of idinlist into the loop that splits the parents into "new" parents (i.e. those of which this is the first child) and "old" parents. Unfortunately this is incorrect in the case where we hit the break statement a few lines further down, since when we come back in, we'll see idinlist($p) set for some parents that aren't in the list. This fixes it by moving the loop that sets up newolds and oldolds further down. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-13 06:52:00 +02:00
}
}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
}
return $ret
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
proc make_idlist {row} {
global displayorder parentlist uparrowlen downarrowlen mingaplen
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
global commitidx curview children
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set r [expr {$row - $mingaplen - $downarrowlen - 1}]
if {$r < 0} {
set r 0
gitk: Get rid of the rowchk array Instead, when looking for lines that should be terminated with a down arrow, we look at the parents of the commit $downarrowlen + 1 rows before. This gets rid of one more place where we are assuming that all the rows are laid out in order from top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-24 14:16:42 +02:00
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set ra [expr {$row - $downarrowlen}]
if {$ra < 0} {
set ra 0
}
set rb [expr {$row + $uparrowlen}]
if {$rb > $commitidx($curview)} {
set rb $commitidx($curview)
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
make_disporder $r [expr {$rb + 1}]
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set ids {}
for {} {$r < $ra} {incr r} {
set nextid [lindex $displayorder [expr {$r + 1}]]
foreach p [lindex $parentlist $r] {
if {$p eq $nextid} continue
set rn [nextuse $p $r]
if {$rn >= $row &&
$rn <= $r + $downarrowlen + $mingaplen + $uparrowlen} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
lappend ids [list [ordertoken $p] $p]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
}
for {} {$r < $row} {incr r} {
set nextid [lindex $displayorder [expr {$r + 1}]]
foreach p [lindex $parentlist $r] {
if {$p eq $nextid} continue
set rn [nextuse $p $r]
if {$rn < 0 || $rn >= $row} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
lappend ids [list [ordertoken $p] $p]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
}
set id [lindex $displayorder $row]
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
lappend ids [list [ordertoken $id] $id]
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
while {$r < $rb} {
foreach p [lindex $parentlist $r] {
set firstkid [lindex $children($curview,$p) 0]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[rowofcommit $firstkid] < $row} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
lappend ids [list [ordertoken $p] $p]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
incr r
set id [lindex $displayorder $r]
if {$id ne {}} {
set firstkid [lindex $children($curview,$id) 0]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$firstkid ne {} && [rowofcommit $firstkid] < $row} {
gitk: Compute row numbers and order tokens lazily Instead of computing ordertok values and arc row numbers in getcommitlines, this defers computing them until they are needed. So getcommitlines no longer calls update_arcrows; instead it gets called from rowofcommit and make_disporder. Things that modify arcs now call modify_arc instead of setting vtokmod/varcmod directly, and modify_arc does the undolayout that used to be in update_arcrows. Also, idcol and make_idlist now use a new ordertoken function instead of the ordertok variable. ordertoken uses ordertok as a cache, but can itself compute the ordering tokens from scratch. This means that the ordering tokens (and hence the layout of the graph) is once again determined by the topological ordering we put on the graph, not on the order in which we see the commits from git log, which improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-11 00:45:38 +01:00
lappend ids [list [ordertoken $id] $id]
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set idlist {}
foreach idx [lsort -unique $ids] {
lappend idlist [lindex $idx 1]
}
return $idlist
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
proc rowsequal {a b} {
while {[set i [lsearch -exact $a {}]] >= 0} {
set a [lreplace $a $i $i]
}
while {[set i [lsearch -exact $b {}]] >= 0} {
set b [lreplace $b $i $i]
}
return [expr {$a eq $b}]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
proc makeupline {id row rend col} {
global rowidlist uparrowlen downarrowlen mingaplen
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
for {set r $rend} {1} {set r $rstart} {
set rstart [prevuse $id $r]
if {$rstart < 0} return
if {$rstart < $row} break
}
if {$rstart + $uparrowlen + $mingaplen + $downarrowlen < $rend} {
set rstart [expr {$rend - $uparrowlen - 1}]
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
for {set r $rstart} {[incr r] <= $row} {} {
set idlist [lindex $rowidlist $r]
if {$idlist ne {} && [lsearch -exact $idlist $id] < 0} {
set col [idcol $idlist $id $col]
lset rowidlist $r [linsert $idlist $col $id]
changedrow $r
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
proc layoutrows {row endrow} {
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
global rowidlist rowisopt rowfinal displayorder
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global uparrowlen downarrowlen maxwidth mingaplen
global children parentlist
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global commitidx viewcomplete curview
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
make_disporder [expr {$row - 1}] [expr {$endrow + $uparrowlen}]
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set idlist {}
if {$row > 0} {
gitk: Fix bugs in setting rowfinal We weren't updating the rowfinal list in insertrow and removerow, so it was getting out of sync with rowidlist, which resulted in Tcl errors. This also optimizes the setting of rowfinal in layoutrows a bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-15 01:04:11 +02:00
set rm1 [expr {$row - 1}]
foreach id [lindex $rowidlist $rm1] {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
if {$id ne {}} {
lappend idlist $id
}
}
gitk: Fix bugs in setting rowfinal We weren't updating the rowfinal list in insertrow and removerow, so it was getting out of sync with rowidlist, which resulted in Tcl errors. This also optimizes the setting of rowfinal in layoutrows a bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-15 01:04:11 +02:00
set final [lindex $rowfinal $rm1]
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
for {} {$row < $endrow} {incr row} {
set rm1 [expr {$row - 1}]
gitk: Fix bugs in setting rowfinal We weren't updating the rowfinal list in insertrow and removerow, so it was getting out of sync with rowidlist, which resulted in Tcl errors. This also optimizes the setting of rowfinal in layoutrows a bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-15 01:04:11 +02:00
if {$rm1 < 0 || $idlist eq {}} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set idlist [make_idlist $row]
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
set final 1
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
} else {
set id [lindex $displayorder $rm1]
set col [lsearch -exact $idlist $id]
set idlist [lreplace $idlist $col $col]
foreach p [lindex $parentlist $rm1] {
if {[lsearch -exact $idlist $p] < 0} {
set col [idcol $idlist $p $col]
set idlist [linsert $idlist $col $p]
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
# if not the first child, we have to insert a line going up
if {$id ne [lindex $children($curview,$p) 0]} {
makeupline $p $rm1 $row $col
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
}
}
set id [lindex $displayorder $row]
if {$row > $downarrowlen} {
set termrow [expr {$row - $downarrowlen - 1}]
foreach p [lindex $parentlist $termrow] {
set i [lsearch -exact $idlist $p]
if {$i < 0} continue
set nr [nextuse $p $termrow]
if {$nr < 0 || $nr >= $row + $mingaplen + $uparrowlen} {
set idlist [lreplace $idlist $i $i]
}
}
}
set col [lsearch -exact $idlist $id]
if {$col < 0} {
set col [idcol $idlist $id]
set idlist [linsert $idlist $col $id]
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
if {$children($curview,$id) ne {}} {
makeupline $id $rm1 $row $col
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
}
set r [expr {$row + $uparrowlen - 1}]
if {$r < $commitidx($curview)} {
set x $col
foreach p [lindex $parentlist $r] {
if {[lsearch -exact $idlist $p] >= 0} continue
set fk [lindex $children($curview,$p) 0]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[rowofcommit $fk] < $row} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set x [idcol $idlist $p $x]
set idlist [linsert $idlist $x $p]
}
}
if {[incr r] < $commitidx($curview)} {
set p [lindex $displayorder $r]
if {[lsearch -exact $idlist $p] < 0} {
set fk [lindex $children($curview,$p) 0]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$fk ne {} && [rowofcommit $fk] < $row} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set x [idcol $idlist $p $x]
set idlist [linsert $idlist $x $p]
}
}
}
}
}
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
if {$final && !$viewcomplete($curview) &&
$row + $uparrowlen + $mingaplen + $downarrowlen
>= $commitidx($curview)} {
set final 0
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set l [llength $rowidlist]
if {$row == $l} {
lappend rowidlist $idlist
lappend rowisopt 0
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
lappend rowfinal $final
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
} elseif {$row < $l} {
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
if {![rowsequal $idlist [lindex $rowidlist $row]]} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
lset rowidlist $row $idlist
changedrow $row
}
gitk: Fix bugs in setting rowfinal We weren't updating the rowfinal list in insertrow and removerow, so it was getting out of sync with rowidlist, which resulted in Tcl errors. This also optimizes the setting of rowfinal in layoutrows a bit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-15 01:04:11 +02:00
lset rowfinal $row $final
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
} else {
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
set pad [ntimes [expr {$row - $l}] {}]
set rowidlist [concat $rowidlist $pad]
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
lappend rowidlist $idlist
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
set rowfinal [concat $rowfinal $pad]
lappend rowfinal $final
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set rowisopt [concat $rowisopt [ntimes [expr {$row - $l + 1}] 0]]
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
return $row
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
proc changedrow {row} {
global displayorder iddrawn rowisopt need_redisplay
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set l [llength $rowisopt]
if {$row < $l} {
lset rowisopt $row 0
if {$row + 1 < $l} {
lset rowisopt [expr {$row + 1}] 0
if {$row + 2 < $l} {
lset rowisopt [expr {$row + 2}] 0
}
}
}
set id [lindex $displayorder $row]
if {[info exists iddrawn($id)]} {
set need_redisplay 1
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
proc insert_pad {row col npad} {
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
global rowidlist
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set pad [ntimes $npad {}]
gitk: Eliminate diagonal arrows This changes the optimizer to insert pads to straighten downward pointing arrows so they point straight down. When drawing the parent link to the first child in drawlineseg, this draws it with 3 segments like other parent links if it is only one row high with an arrow. These two things mean we can dispense with the workarounds for arrows on diagonal segments. This also fixes a couple of other minor bugs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 04:42:57 +02:00
set idlist [lindex $rowidlist $row]
set bef [lrange $idlist 0 [expr {$col - 1}]]
set aft [lrange $idlist $col end]
set i [lsearch -exact $aft {}]
if {$i > 0} {
set aft [lreplace $aft $i $i]
}
lset rowidlist $row [concat $bef $pad $aft]
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
changedrow $row
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
proc optimize_rows {row col endrow} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global rowidlist rowisopt displayorder curview children
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
if {$row < 1} {
set row 1
}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
for {} {$row < $endrow} {incr row; set col 0} {
if {[lindex $rowisopt $row]} continue
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set haspad 0
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set y0 [expr {$row - 1}]
set ym [expr {$row - 2}]
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set idlist [lindex $rowidlist $row]
set previdlist [lindex $rowidlist $y0]
if {$idlist eq {} || $previdlist eq {}} continue
if {$ym >= 0} {
set pprevidlist [lindex $rowidlist $ym]
if {$pprevidlist eq {}} continue
} else {
set pprevidlist {}
}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set x0 -1
set xm -1
for {} {$col < [llength $idlist]} {incr col} {
set id [lindex $idlist $col]
if {[lindex $previdlist $col] eq $id} continue
if {$id eq {}} {
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set haspad 1
continue
}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set x0 [lsearch -exact $previdlist $id]
if {$x0 < 0} continue
set z [expr {$x0 - $col}]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set isarrow 0
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set z0 {}
if {$ym >= 0} {
set xm [lsearch -exact $pprevidlist $id]
if {$xm >= 0} {
set z0 [expr {$xm - $x0}]
}
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
if {$z0 eq {}} {
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
# if row y0 is the first child of $id then it's not an arrow
if {[lindex $children($curview,$id) 0] ne
[lindex $displayorder $y0]} {
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set isarrow 1
}
}
gitk: Eliminate diagonal arrows This changes the optimizer to insert pads to straighten downward pointing arrows so they point straight down. When drawing the parent link to the first child in drawlineseg, this draws it with 3 segments like other parent links if it is only one row high with an arrow. These two things mean we can dispense with the workarounds for arrows on diagonal segments. This also fixes a couple of other minor bugs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 04:42:57 +02:00
if {!$isarrow && $id ne [lindex $displayorder $row] &&
[lsearch -exact [lindex $rowidlist [expr {$row+1}]] $id] < 0} {
set isarrow 1
}
gitk: Add some more comments to the optimize_rows procedure Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-15 01:45:23 +02:00
# Looking at lines from this row to the previous row,
# make them go straight up if they end in an arrow on
# the previous row; otherwise make them go straight up
# or at 45 degrees.
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
if {$z < -1 || ($z < 0 && $isarrow)} {
gitk: Add some more comments to the optimize_rows procedure Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-15 01:45:23 +02:00
# Line currently goes left too much;
# insert pads in the previous row, then optimize it
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set npad [expr {-1 - $z + $isarrow}]
insert_pad $y0 $x0 $npad
if {$y0 > 0} {
optimize_rows $y0 $x0 $row
}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set previdlist [lindex $rowidlist $y0]
set x0 [lsearch -exact $previdlist $id]
set z [expr {$x0 - $col}]
if {$z0 ne {}} {
set pprevidlist [lindex $rowidlist $ym]
set xm [lsearch -exact $pprevidlist $id]
set z0 [expr {$xm - $x0}]
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
} elseif {$z > 1 || ($z > 0 && $isarrow)} {
gitk: Add some more comments to the optimize_rows procedure Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-15 01:45:23 +02:00
# Line currently goes right too much;
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
# insert pads in this line
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set npad [expr {$z - 1 + $isarrow}]
gitk: Eliminate diagonal arrows This changes the optimizer to insert pads to straighten downward pointing arrows so they point straight down. When drawing the parent link to the first child in drawlineseg, this draws it with 3 segments like other parent links if it is only one row high with an arrow. These two things mean we can dispense with the workarounds for arrows on diagonal segments. This also fixes a couple of other minor bugs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 04:42:57 +02:00
insert_pad $row $col $npad
set idlist [lindex $rowidlist $row]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
incr col $npad
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set z [expr {$x0 - $col}]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set haspad 1
}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
if {$z0 eq {} && !$isarrow && $ym >= 0} {
gitk: Improve appearance of first child links The point where the line for a parent joins to the first child shown is visually different from the lines to the other children, because the line doesn't branch, but terminates at the child. Because of this, we now treat the first child a little differently in the optimizer, and we draw its link in drawlineseg rather than drawparentlinks. This improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 13:11:37 +01:00
# this line links to its first child on row $row-2
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set id [lindex $displayorder $ym]
set xc [lsearch -exact $pprevidlist $id]
gitk: Improve appearance of first child links The point where the line for a parent joins to the first child shown is visually different from the lines to the other children, because the line doesn't branch, but terminates at the child. Because of this, we now treat the first child a little differently in the optimizer, and we draw its link in drawlineseg rather than drawparentlinks. This improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 13:11:37 +01:00
if {$xc >= 0} {
set z0 [expr {$xc - $x0}]
}
}
gitk: Add some more comments to the optimize_rows procedure Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-15 01:45:23 +02:00
# avoid lines jigging left then immediately right
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
if {$z0 ne {} && $z < 0 && $z0 > 0} {
insert_pad $y0 $x0 1
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
incr x0
optimize_rows $y0 $x0 $row
set previdlist [lindex $rowidlist $y0]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
if {!$haspad} {
gitk: Add some more comments to the optimize_rows procedure Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-15 01:45:23 +02:00
# Find the first column that doesn't have a line going right
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
for {set col [llength $idlist]} {[incr col -1] >= 0} {} {
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set id [lindex $idlist $col]
if {$id eq {}} break
set x0 [lsearch -exact $previdlist $id]
if {$x0 < 0} {
gitk: Improve appearance of first child links The point where the line for a parent joins to the first child shown is visually different from the lines to the other children, because the line doesn't branch, but terminates at the child. Because of this, we now treat the first child a little differently in the optimizer, and we draw its link in drawlineseg rather than drawparentlinks. This improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 13:11:37 +01:00
# check if this is the link to the first child
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
set kid [lindex $displayorder $y0]
if {[lindex $children($curview,$id) 0] eq $kid} {
gitk: Improve appearance of first child links The point where the line for a parent joins to the first child shown is visually different from the lines to the other children, because the line doesn't branch, but terminates at the child. Because of this, we now treat the first child a little differently in the optimizer, and we draw its link in drawlineseg rather than drawparentlinks. This improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 13:11:37 +01:00
# it is, work out offset to child
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
set x0 [lsearch -exact $previdlist $kid]
gitk: Improve appearance of first child links The point where the line for a parent joins to the first child shown is visually different from the lines to the other children, because the line doesn't branch, but terminates at the child. Because of this, we now treat the first child a little differently in the optimizer, and we draw its link in drawlineseg rather than drawparentlinks. This improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 13:11:37 +01:00
}
}
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
if {$x0 <= $col} break
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Add some more comments to the optimize_rows procedure Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-15 01:45:23 +02:00
# Insert a pad at that column as long as it has a line and
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
# isn't the last column
if {$x0 >= 0 && [incr col] < [llength $idlist]} {
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set idlist [linsert $idlist $col {}]
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
lset rowidlist $row $idlist
changedrow $row
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
}
}
proc xc {row col} {
global canvx0 linespc
return [expr {$canvx0 + $col * $linespc}]
}
proc yc {row} {
global canvy0 linespc
return [expr {$canvy0 + $row * $linespc}]
}
gitk: Fix a bug in drawing the selected line as a thick line If you clicked on a line, so that it was drawn double-thickness, and then scrolled to bring on-screen a child that hadn't previously been drawn, the lines from it to the selected line were drawn single-thickness. This fixes it so they are drawn double-thickness. This also removes an unnecessary setting of phase in drawrest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 13:00:44 +01:00
proc linewidth {id} {
global thickerline lthickness
set wid $lthickness
if {[info exists thickerline] && $id eq $thickerline} {
set wid [expr {2 * $lthickness}]
}
return $wid
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
proc rowranges {id} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global curview children uparrowlen downarrowlen
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
global rowidlist
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
set kids $children($curview,$id)
if {$kids eq {}} {
return {}
gitk: Store ids in rowrangelist and idrowranges rather than row numbers This removes the need for insertrow to go through rowrangelist and idrowranges and adjust a lot of entries. The first entry for a given id is now the row number of the first child, not that row number + 1, and rowranges compensates for that so its callers didn't have to change. This adds a ranges argument to drawlineseg so that we can avoid calling rowranges a second time inside drawlineseg (all its callers already called rowranges). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-14 11:21:02 +02:00
}
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
set ret {}
lappend kids $id
foreach child $kids {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![commitinview $child $curview]} break
set row [rowofcommit $child]
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
if {![info exists prev]} {
lappend ret [expr {$row + 1}]
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
} else {
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
if {$row <= $prevrow} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
puts "oops children of [shortids $id] out of order [shortids $child] $row <= [shortids $prev] $prevrow"
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
}
# see if the line extends the whole way from prevrow to row
if {$row > $prevrow + $uparrowlen + $downarrowlen &&
[lsearch -exact [lindex $rowidlist \
[expr {int(($row + $prevrow) / 2)}]] $id] < 0} {
# it doesn't, see where it ends
set r [expr {$prevrow + $downarrowlen}]
if {[lsearch -exact [lindex $rowidlist $r] $id] < 0} {
while {[incr r -1] > $prevrow &&
[lsearch -exact [lindex $rowidlist $r] $id] < 0} {}
} else {
while {[incr r] <= $row &&
[lsearch -exact [lindex $rowidlist $r] $id] >= 0} {}
incr r -1
}
lappend ret $r
# see where it starts up again
set r [expr {$row - $uparrowlen}]
if {[lsearch -exact [lindex $rowidlist $r] $id] < 0} {
while {[incr r] < $row &&
[lsearch -exact [lindex $rowidlist $r] $id] < 0} {}
} else {
while {[incr r -1] >= $prevrow &&
[lsearch -exact [lindex $rowidlist $r] $id] >= 0} {}
incr r
}
lappend ret $r
}
}
if {$child eq $id} {
lappend ret $row
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set prev $child
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
set prevrow $row
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Get rid of idrowranges and rowrangelist Instead make the rowranges procedure compute its result by looking in the rowidlist entries for the rows around the children of the id and the id itself. This turns out not to take too long, and not having to maintain idrowranges and rowrangelist speeds up the layout. This also makes optimize_rows not use rowranges, since all it really needed was a way to work out if one id is the first child of another, so it can just look at the children list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-22 14:35:28 +02:00
return $ret
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
}
proc drawlineseg {id row endrow arrowlow} {
global rowidlist displayorder iddrawn linesegs
gitk: Eliminate diagonal arrows This changes the optimizer to insert pads to straighten downward pointing arrows so they point straight down. When drawing the parent link to the first child in drawlineseg, this draws it with 3 segments like other parent links if it is only one row high with an arrow. These two things mean we can dispense with the workarounds for arrows on diagonal segments. This also fixes a couple of other minor bugs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 04:42:57 +02:00
global canv colormap linespc curview maxlinelen parentlist
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set cols [list [lsearch -exact [lindex $rowidlist $row] $id]]
set le [expr {$row + 1}]
set arrowhigh 1
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
while {1} {
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set c [lsearch -exact [lindex $rowidlist $le] $id]
if {$c < 0} {
incr le -1
break
}
lappend cols $c
set x [lindex $displayorder $le]
if {$x eq $id} {
set arrowhigh 0
break
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
if {[info exists iddrawn($x)] || $le == $endrow} {
set c [lsearch -exact [lindex $rowidlist [expr {$le+1}]] $id]
if {$c >= 0} {
lappend cols $c
set arrowhigh 0
}
break
}
incr le
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
if {$le <= $row} {
return $row
}
set lines {}
set i 0
set joinhigh 0
if {[info exists linesegs($id)]} {
set lines $linesegs($id)
foreach li $lines {
set r0 [lindex $li 0]
if {$r0 > $row} {
if {$r0 == $le && [lindex $li 1] - $row <= $maxlinelen} {
set joinhigh 1
}
break
}
incr i
}
}
set joinlow 0
if {$i > 0} {
set li [lindex $lines [expr {$i-1}]]
set r1 [lindex $li 1]
if {$r1 == $row && $le - [lindex $li 0] <= $maxlinelen} {
set joinlow 1
}
}
set x [lindex $cols [expr {$le - $row}]]
set xp [lindex $cols [expr {$le - 1 - $row}]]
set dir [expr {$xp - $x}]
if {$joinhigh} {
set ith [lindex $lines $i 2]
set coords [$canv coords $ith]
set ah [$canv itemcget $ith -arrow]
set arrowhigh [expr {$ah eq "first" || $ah eq "both"}]
set x2 [lindex $cols [expr {$le + 1 - $row}]]
if {$x2 ne {} && $x - $x2 == $dir} {
set coords [lrange $coords 0 end-2]
}
} else {
set coords [list [xc $le $x] [yc $le]]
}
if {$joinlow} {
set itl [lindex $lines [expr {$i-1}] 2]
set al [$canv itemcget $itl -arrow]
set arrowlow [expr {$al eq "last" || $al eq "both"}]
gitk: Eliminate diagonal arrows This changes the optimizer to insert pads to straighten downward pointing arrows so they point straight down. When drawing the parent link to the first child in drawlineseg, this draws it with 3 segments like other parent links if it is only one row high with an arrow. These two things mean we can dispense with the workarounds for arrows on diagonal segments. This also fixes a couple of other minor bugs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 04:42:57 +02:00
} elseif {$arrowlow} {
if {[lsearch -exact [lindex $rowidlist [expr {$row-1}]] $id] >= 0 ||
[lsearch -exact [lindex $parentlist [expr {$row-1}]] $id] >= 0} {
set arrowlow 0
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
}
set arrow [lindex {none first last both} [expr {$arrowhigh + 2*$arrowlow}]]
for {set y $le} {[incr y -1] > $row} {} {
set x $xp
set xp [lindex $cols [expr {$y - 1 - $row}]]
set ndir [expr {$xp - $x}]
if {$dir != $ndir || $xp < 0} {
lappend coords [xc $y $x] [yc $y]
}
set dir $ndir
}
if {!$joinlow} {
if {$xp < 0} {
# join parent line to first child
set ch [lindex $displayorder $row]
set xc [lsearch -exact [lindex $rowidlist $row] $ch]
if {$xc < 0} {
puts "oops: drawlineseg: child $ch not on row $row"
gitk: Eliminate diagonal arrows This changes the optimizer to insert pads to straighten downward pointing arrows so they point straight down. When drawing the parent link to the first child in drawlineseg, this draws it with 3 segments like other parent links if it is only one row high with an arrow. These two things mean we can dispense with the workarounds for arrows on diagonal segments. This also fixes a couple of other minor bugs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 04:42:57 +02:00
} elseif {$xc != $x} {
if {($arrowhigh && $le == $row + 1) || $dir == 0} {
set d [expr {int(0.5 * $linespc)}]
set x1 [xc $row $x]
if {$xc < $x} {
set x2 [expr {$x1 - $d}]
} else {
set x2 [expr {$x1 + $d}]
}
set y2 [yc $row]
set y1 [expr {$y2 + $d}]
lappend coords $x1 $y1 $x2 $y2
} elseif {$xc < $x - 1} {
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
lappend coords [xc $row [expr {$x-1}]] [yc $row]
} elseif {$xc > $x + 1} {
lappend coords [xc $row [expr {$x+1}]] [yc $row]
}
set x $xc
gitk: Improve appearance of first child links The point where the line for a parent joins to the first child shown is visually different from the lines to the other children, because the line doesn't branch, but terminates at the child. Because of this, we now treat the first child a little differently in the optimizer, and we draw its link in drawlineseg rather than drawparentlinks. This improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 13:11:37 +01:00
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
lappend coords [xc $row $x] [yc $row]
} else {
set xn [xc $row $xp]
set yn [yc $row]
gitk: Eliminate diagonal arrows This changes the optimizer to insert pads to straighten downward pointing arrows so they point straight down. When drawing the parent link to the first child in drawlineseg, this draws it with 3 segments like other parent links if it is only one row high with an arrow. These two things mean we can dispense with the workarounds for arrows on diagonal segments. This also fixes a couple of other minor bugs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 04:42:57 +02:00
lappend coords $xn $yn
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
}
if {!$joinhigh} {
assigncolor $id
set t [$canv create line $coords -width [linewidth $id] \
-fill $colormap($id) -tags lines.$id -arrow $arrow]
$canv lower $t
bindline $t $id
set lines [linsert $lines $i [list $row $le $t]]
} else {
$canv coords $ith $coords
if {$arrow ne $ah} {
$canv itemconf $ith -arrow $arrow
}
lset lines $i 0 $row
}
} else {
set xo [lsearch -exact [lindex $rowidlist [expr {$row - 1}]] $id]
set ndir [expr {$xo - $xp}]
set clow [$canv coords $itl]
if {$dir == $ndir} {
set clow [lrange $clow 2 end]
}
set coords [concat $coords $clow]
if {!$joinhigh} {
lset lines [expr {$i-1}] 1 $le
} else {
# coalesce two pieces
$canv delete $ith
set b [lindex $lines [expr {$i-1}] 0]
set e [lindex $lines $i 1]
set lines [lreplace $lines [expr {$i-1}] $i [list $b $e $itl]]
}
$canv coords $itl $coords
if {$arrow ne $al} {
$canv itemconf $itl -arrow $arrow
gitk: Better workaround for arrows on diagonal line segments Instead of adding extra padding to create a vertical line segment at the lower end of a line that has an arrow, this now just draws a very short vertical line segment at the lower end. This alternative workaround for the Tk8.4 behaviour (not drawing arrows on diagonal line segments) doesn't have the problem of making the graph very wide when people do a lot of merges in a row (hi Junio :). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 01:45:14 +02:00
}
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set linesegs($id) $lines
return $le
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
proc drawparentlinks {id row} {
global rowidlist canv colormap curview parentlist
gitk: Improve the drawing of links to parent lines The way gitk used to draw the lines joining a commit to the lines representing its parents was sometimes visually ambiguous, especially when the line to the parent had a corner that coincided with a corner on another line. This improves things by using a smaller slanting section on the line joining a commit to a parent line if the parent line is vertical where it joins on. It also optimizes the drawing a little in the case where the parent line slants towards this commit already. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-01 14:27:57 +02:00
global idpos linespc
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set rowids [lindex $rowidlist $row]
set col [lsearch -exact $rowids $id]
if {$col < 0} return
set olds [lindex $parentlist $row]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set row2 [expr {$row + 1}]
set x [xc $row $col]
set y [yc $row]
set y2 [yc $row2]
gitk: Eliminate diagonal arrows This changes the optimizer to insert pads to straighten downward pointing arrows so they point straight down. When drawing the parent link to the first child in drawlineseg, this draws it with 3 segments like other parent links if it is only one row high with an arrow. These two things mean we can dispense with the workarounds for arrows on diagonal segments. This also fixes a couple of other minor bugs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 04:42:57 +02:00
set d [expr {int(0.5 * $linespc)}]
gitk: Improve the drawing of links to parent lines The way gitk used to draw the lines joining a commit to the lines representing its parents was sometimes visually ambiguous, especially when the line to the parent had a corner that coincided with a corner on another line. This improves things by using a smaller slanting section on the line joining a commit to a parent line if the parent line is vertical where it joins on. It also optimizes the drawing a little in the case where the parent line slants towards this commit already. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-01 14:27:57 +02:00
set ymid [expr {$y + $d}]
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
set ids [lindex $rowidlist $row2]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
# rmx = right-most X coord used
set rmx 0
foreach p $olds {
gitk: Prevent parent link from overwriting commit headline When I made drawlineseg responsible for drawing the link to the first child rather than drawparentlinks, that meant that the right-most X value computed by drawparentlinks didn't include those first-child links, and thus the first-child link could go over the top of the commit headline. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 00:54:24 +02:00
set i [lsearch -exact $ids $p]
if {$i < 0} {
puts "oops, parent $p of $id not in list"
continue
}
set x2 [xc $row2 $i]
if {$x2 > $rmx} {
set rmx $x2
}
gitk: Improve the drawing of links to parent lines The way gitk used to draw the lines joining a commit to the lines representing its parents was sometimes visually ambiguous, especially when the line to the parent had a corner that coincided with a corner on another line. This improves things by using a smaller slanting section on the line joining a commit to a parent line if the parent line is vertical where it joins on. It also optimizes the drawing a little in the case where the parent line slants towards this commit already. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-01 14:27:57 +02:00
set j [lsearch -exact $rowids $p]
if {$j < 0} {
gitk: Improve appearance of first child links The point where the line for a parent joins to the first child shown is visually different from the lines to the other children, because the line doesn't branch, but terminates at the child. Because of this, we now treat the first child a little differently in the optimizer, and we draw its link in drawlineseg rather than drawparentlinks. This improves the appearance of the graph. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-18 13:11:37 +01:00
# drawlineseg will do this one for us
continue
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
assigncolor $p
# should handle duplicated parents here...
set coords [list $x $y]
gitk: Improve the drawing of links to parent lines The way gitk used to draw the lines joining a commit to the lines representing its parents was sometimes visually ambiguous, especially when the line to the parent had a corner that coincided with a corner on another line. This improves things by using a smaller slanting section on the line joining a commit to a parent line if the parent line is vertical where it joins on. It also optimizes the drawing a little in the case where the parent line slants towards this commit already. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-01 14:27:57 +02:00
if {$i != $col} {
# if attaching to a vertical segment, draw a smaller
# slant for visual distinctness
if {$i == $j} {
if {$i < $col} {
lappend coords [expr {$x2 + $d}] $y $x2 $ymid
} else {
lappend coords [expr {$x2 - $d}] $y $x2 $ymid
}
} elseif {$i < $col && $i < $j} {
# segment slants towards us already
lappend coords [xc $row $j] $y
} else {
if {$i < $col - 1} {
lappend coords [expr {$x2 + $linespc}] $y
} elseif {$i > $col + 1} {
lappend coords [expr {$x2 - $linespc}] $y
}
lappend coords $x2 $y2
}
} else {
lappend coords $x2 $y2
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Fix a bug in drawing the selected line as a thick line If you clicked on a line, so that it was drawn double-thickness, and then scrolled to bring on-screen a child that hadn't previously been drawn, the lines from it to the selected line were drawn single-thickness. This fixes it so they are drawn double-thickness. This also removes an unnecessary setting of phase in drawrest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 13:00:44 +01:00
set t [$canv create line $coords -width [linewidth $p] \
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
-fill $colormap($p) -tags lines.$p]
$canv lower $t
bindline $t $p
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
if {$rmx > [lindex $idpos($id) 1]} {
lset idpos($id) 1 $rmx
redrawtags $id
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Fix a bug in drawing the selected line as a thick line If you clicked on a line, so that it was drawn double-thickness, and then scrolled to bring on-screen a child that hadn't previously been drawn, the lines from it to the selected line were drawn single-thickness. This fixes it so they are drawn double-thickness. This also removes an unnecessary setting of phase in drawrest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 13:00:44 +01:00
proc drawlines {id} {
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
global canv
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
$canv itemconf lines.$id -width [linewidth $id]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
proc drawcmittext {id row col} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global linespc canv canv2 canv3 fgcolor curview
global cmitlisted commitinfo rowidlist parentlist
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
global rowtextx idpos idtags idheads idotherrefs
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global linehtag linentag linedtag selectedline
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
global canvxmax boldids boldnameids fgcolor markedid
gitk: Use <Button-2> for context menus on OSX An OSX user has reported that gitk's context menus are not usable under OSX because it doesn't provide a way to generate <Button-3> events. Users can generate <Button-2> events with command+click, so use that for the context menus instead on OSX. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-22 01:11:37 +02:00
global mainheadid nullid nullid2 circleitem circlecolors ctxbut
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
[PATCH] gitk: learn --show-all output It's really not very easy to visualize the commit walker, because - on purpose - it obvously doesn't show the uninteresting commits! We will soon add a "--show-all" flag to the revision walker, which will make it show uninteresting commits too, and they'll have a '^' in front of them. This is to update 'gitk' to show those negative commits in gray to futureproof it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-09 23:02:07 +01:00
# listed is 0 for boundary, 1 for normal, 2 for negative, 3 for left, 4 for right
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set listed $cmitlisted($curview,$id)
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
if {$id eq $nullid} {
set ofill red
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
} elseif {$id eq $nullid2} {
gitk: Make the fake commit for the index changes green rather than magenta The magenta was a bit close in color to the normal blue commits. This makes them green instead as suggested by Linus. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-22 14:05:30 +02:00
set ofill green
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
} elseif {$id eq $mainheadid} {
set ofill yellow
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
} else {
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
set ofill [lindex $circlecolors $listed]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set x [xc $row $col]
set y [yc $row]
set orad [expr {$linespc / 3}]
[PATCH] gitk: learn --show-all output It's really not very easy to visualize the commit walker, because - on purpose - it obvously doesn't show the uninteresting commits! We will soon add a "--show-all" flag to the revision walker, which will make it show uninteresting commits too, and they'll have a '^' in front of them. This is to update 'gitk' to show those negative commits in gray to futureproof it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-09 23:02:07 +01:00
if {$listed <= 2} {
gitk: Use git log and add support for --left-right This is based on patches from Linus Torvalds and Junio Hamano, so the ideas here are theirs. This makes gitk use "git log -z --pretty=raw" instead of "git rev-list" to generate the list of commits, and also makes it grok the "<" and ">" markers that git log (and git rev-list) output with the --left-right flag to indicate which side of a symmetric diff a commit is reachable from. Left-side commits are drawn with a triangle pointing leftwards instead of a circle, and right-side commits are drawn with a triangle pointing rightwards. The commitlisted list is used to store the left/right information as well as the information about whether each commit is on the boundary. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-09 14:45:47 +02:00
set t [$canv create oval [expr {$x - $orad}] [expr {$y - $orad}] \
[expr {$x + $orad - 1}] [expr {$y + $orad - 1}] \
-fill $ofill -outline $fgcolor -width 1 -tags circle]
[PATCH] gitk: learn --show-all output It's really not very easy to visualize the commit walker, because - on purpose - it obvously doesn't show the uninteresting commits! We will soon add a "--show-all" flag to the revision walker, which will make it show uninteresting commits too, and they'll have a '^' in front of them. This is to update 'gitk' to show those negative commits in gray to futureproof it. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-09 23:02:07 +01:00
} elseif {$listed == 3} {
gitk: Use git log and add support for --left-right This is based on patches from Linus Torvalds and Junio Hamano, so the ideas here are theirs. This makes gitk use "git log -z --pretty=raw" instead of "git rev-list" to generate the list of commits, and also makes it grok the "<" and ">" markers that git log (and git rev-list) output with the --left-right flag to indicate which side of a symmetric diff a commit is reachable from. Left-side commits are drawn with a triangle pointing leftwards instead of a circle, and right-side commits are drawn with a triangle pointing rightwards. The commitlisted list is used to store the left/right information as well as the information about whether each commit is on the boundary. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-09 14:45:47 +02:00
# triangle pointing left for left-side commits
set t [$canv create polygon \
[expr {$x - $orad}] $y \
[expr {$x + $orad - 1}] [expr {$y - $orad}] \
[expr {$x + $orad - 1}] [expr {$y + $orad - 1}] \
-fill $ofill -outline $fgcolor -width 1 -tags circle]
} else {
# triangle pointing right for right-side commits
set t [$canv create polygon \
[expr {$x + $orad - 1}] $y \
[expr {$x - $orad}] [expr {$y - $orad}] \
[expr {$x - $orad}] [expr {$y + $orad - 1}] \
-fill $ofill -outline $fgcolor -width 1 -tags circle]
}
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
set circleitem($row) $t
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
$canv raise $t
$canv bind $t <1> {selcanvline {} %x %y}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set rmx [llength [lindex $rowidlist $row]]
set olds [lindex $parentlist $row]
if {$olds ne {}} {
set nextids [lindex $rowidlist [expr {$row + 1}]]
foreach p $olds {
set i [lsearch -exact $nextids $p]
if {$i > $rmx} {
set rmx $i
}
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set xt [xc $row $rmx]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set rowtextx($row) $xt
set idpos($id) [list $x $xt $y]
if {[info exists idtags($id)] || [info exists idheads($id)]
|| [info exists idotherrefs($id)]} {
set xt [drawtags $id $x $xt $y]
}
set headline [lindex $commitinfo($id) 0]
set name [lindex $commitinfo($id) 1]
set date [lindex $commitinfo($id) 2]
set date [formatdate $date]
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set font mainfont
set nfont mainfont
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
set isbold [ishighlighted $id]
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
if {$isbold > 0} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
lappend boldids $id
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set font mainfontbold
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
if {$isbold > 1} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
lappend boldnameids $id
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set nfont mainfontbold
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set linehtag($id) [$canv create text $xt $y -anchor w -fill $fgcolor \
-text $headline -font $font -tags text]
$canv bind $linehtag($id) $ctxbut "rowmenu %X %Y $id"
set linentag($id) [$canv2 create text 3 $y -anchor w -fill $fgcolor \
-text $name -font $nfont -tags text]
set linedtag($id) [$canv3 create text 3 $y -anchor w -fill $fgcolor \
-text $date -font mainfont -tags text]
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline == $row} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
make_secsel $id
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
}
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
if {[info exists markedid] && $markedid eq $id} {
make_idmark $id
}
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set xr [expr {$xt + [font measure $font $headline]}]
gitk: Allow top panes to scroll horizontally with mouse button 2 Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 00:55:11 +02:00
if {$xr > $canvxmax} {
set canvxmax $xr
setcanvscroll
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
proc drawcmitrow {row} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global displayorder rowidlist nrows_drawn
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
global iddrawn markingmatches
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global commitinfo numcommits
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
global filehighlight fhighlights findpattern nhighlights
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
global hlview vhighlights
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
global highlight_related rhighlights
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
if {$row >= $numcommits} return
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set id [lindex $displayorder $row]
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {[info exists hlview] && ![info exists vhighlights($id)]} {
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
askvhighlight $row $id
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {[info exists filehighlight] && ![info exists fhighlights($id)]} {
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
askfilehighlight $row $id
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {$findpattern ne {} && ![info exists nhighlights($id)]} {
gitk: Move "pickaxe" find function to highlight facility This removes the "Files" and "Pickaxe" parts of the "Find" function, so Find is now just about searching the commit data. We now highlight the commits that match the Find string (without having to press Find), and have a drop-down menu for selecting whether the git-diff-tree based highlighting is done on paths or on adding/removing a given string. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 02:43:47 +02:00
askfindhighlight $row $id
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {$highlight_related ne [mc "None"] && ![info exists rhighlights($id)]} {
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
askrelhighlight $row $id
}
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
if {![info exists iddrawn($id)]} {
set col [lsearch -exact [lindex $rowidlist $row] $id]
if {$col < 0} {
puts "oops, row $row id $id not in list"
return
}
if {![info exists commitinfo($id)]} {
getcommit $id
}
assigncolor $id
drawcmittext $id $row $col
set iddrawn($id) 1
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
incr nrows_drawn
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
if {$markingmatches} {
markrowmatches $row $id
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
proc drawcommits {row {endrow {}}} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global numcommits iddrawn displayorder curview need_redisplay
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
global parentlist rowidlist rowfinal uparrowlen downarrowlen nrows_drawn
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
if {$row < 0} {
set row 0
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
if {$endrow eq {}} {
set endrow $row
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
if {$endrow >= $numcommits} {
set endrow [expr {$numcommits - 1}]
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set rl1 [expr {$row - $downarrowlen - 3}]
if {$rl1 < 0} {
set rl1 0
}
set ro1 [expr {$row - 3}]
if {$ro1 < 0} {
set ro1 0
}
set r2 [expr {$endrow + $uparrowlen + 3}]
if {$r2 > $numcommits} {
set r2 $numcommits
}
for {set r $rl1} {$r < $r2} {incr r} {
gitk: Make it possible to lay out all the rows we have received so far This arranges things so that we can do the layout all the way up to the last commit that we have received from git log. If we get more commits we re-lay and redisplay (if necessary) the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-04 18:19:56 +02:00
if {[lindex $rowidlist $r] ne {} && [lindex $rowfinal $r]} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
if {$rl1 < $r} {
layoutrows $rl1 $r
}
set rl1 [expr {$r + 1}]
}
}
if {$rl1 < $r} {
layoutrows $rl1 $r
}
optimize_rows $ro1 0 $r2
if {$need_redisplay || $nrows_drawn > 2000} {
clear_display
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
# make the lines join to already-drawn rows either side
set r [expr {$row - 1}]
if {$r < 0 || ![info exists iddrawn([lindex $displayorder $r])]} {
set r $row
}
set er [expr {$endrow + 1}]
if {$er >= $numcommits ||
![info exists iddrawn([lindex $displayorder $er])]} {
set er $endrow
}
for {} {$r <= $er} {incr r} {
set id [lindex $displayorder $r]
set wasdrawn [info exists iddrawn($id)]
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
drawcmitrow $r
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
if {$r == $er} break
set nextid [lindex $displayorder [expr {$r + 1}]]
gitk: Fix "can't unset prevlines(...)" Tcl error This fixes the error reported by Michele Ballabio, where gitk will throw a Tcl error "can't unset prevlines(...)" when displaying a commit that has a parent commit listed more than once, and the commit is the first child of that parent. The problem was basically that we had two variables, prevlines and lineends, and were relying on the invariant that prevlines($id) was set iff $id was in the lineends($r) list for some $r. But having a duplicate parent breaks that invariant since we end up with the parent listed twice in lineends. This fixes it by simplifying the logic to use only a single variable, lineend. It also rearranges things a little so that we don't try to draw the line for the duplicated parent twice. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-21 04:58:42 +02:00
if {$wasdrawn && [info exists iddrawn($nextid)]} continue
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
drawparentlinks $id $r
set rowids [lindex $rowidlist $r]
foreach lid $rowids {
if {$lid eq {}} continue
gitk: Fix "can't unset prevlines(...)" Tcl error This fixes the error reported by Michele Ballabio, where gitk will throw a Tcl error "can't unset prevlines(...)" when displaying a commit that has a parent commit listed more than once, and the commit is the first child of that parent. The problem was basically that we had two variables, prevlines and lineends, and were relying on the invariant that prevlines($id) was set iff $id was in the lineends($r) list for some $r. But having a duplicate parent breaks that invariant since we end up with the parent listed twice in lineends. This fixes it by simplifying the logic to use only a single variable, lineend. It also rearranges things a little so that we don't try to draw the line for the duplicated parent twice. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-21 04:58:42 +02:00
if {[info exists lineend($lid)] && $lineend($lid) > $r} continue
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
if {$lid eq $id} {
# see if this is the first child of any of its parents
foreach p [lindex $parentlist $r] {
if {[lsearch -exact $rowids $p] < 0} {
# make this line extend up to the child
gitk: Fix "can't unset prevlines(...)" Tcl error This fixes the error reported by Michele Ballabio, where gitk will throw a Tcl error "can't unset prevlines(...)" when displaying a commit that has a parent commit listed more than once, and the commit is the first child of that parent. The problem was basically that we had two variables, prevlines and lineends, and were relying on the invariant that prevlines($id) was set iff $id was in the lineends($r) list for some $r. But having a duplicate parent breaks that invariant since we end up with the parent listed twice in lineends. This fixes it by simplifying the logic to use only a single variable, lineend. It also rearranges things a little so that we don't try to draw the line for the duplicated parent twice. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-21 04:58:42 +02:00
set lineend($p) [drawlineseg $p $r $er 0]
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
}
}
gitk: Fix "can't unset prevlines(...)" Tcl error This fixes the error reported by Michele Ballabio, where gitk will throw a Tcl error "can't unset prevlines(...)" when displaying a commit that has a parent commit listed more than once, and the commit is the first child of that parent. The problem was basically that we had two variables, prevlines and lineends, and were relying on the invariant that prevlines($id) was set iff $id was in the lineends($r) list for some $r. But having a duplicate parent breaks that invariant since we end up with the parent listed twice in lineends. This fixes it by simplifying the logic to use only a single variable, lineend. It also rearranges things a little so that we don't try to draw the line for the duplicated parent twice. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-21 04:58:42 +02:00
} else {
set lineend($lid) [drawlineseg $lid $r $er 1]
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
}
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc undolayout {row} {
global uparrowlen mingaplen downarrowlen
global rowidlist rowisopt rowfinal need_redisplay
set r [expr {$row - ($uparrowlen + $mingaplen + $downarrowlen)}]
if {$r < 0} {
set r 0
}
if {[llength $rowidlist] > $r} {
incr r -1
set rowidlist [lrange $rowidlist 0 $r]
set rowfinal [lrange $rowfinal 0 $r]
set rowisopt [lrange $rowisopt 0 $r]
set need_redisplay 1
run drawvisible
}
}
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
proc drawvisible {} {
global canv linespc curview vrowmod selectedline targetrow targetid
gitk: Fix some corner cases in the targetid/targetrow stuff * Make sure targetrow is never >= numcommits * Don't try to do anything about the target row if the targetid is no longer in the view; it'll just cause Tcl errors * In insertrow, increment targetrow if we are inserting the fake commit at or before the target row * In removerow, if we are removing the target row, make it the next one instead. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-01 23:59:39 +01:00
global need_redisplay cscroll numcommits
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
set fs [$canv yview]
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set ymax [lindex [$canv cget -scrollregion] 3]
gitk: Fix bug causing Tcl error when no commits are selected Some of the stuff that commit 31c0eaa8cc10944ebca8aa31fb59f0b77b1b6e77 added to drawvisible isn't appropriate to do when we have no commits, and this was causing a Tcl error if gitk was invoked in such a fashion that no commits were selected. This fixes it by bailing out of drawvisible early if there are no commits displayed. Bug reported by Johannes Sixt. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-15 12:45:36 +01:00
if {$ymax eq {} || $ymax == 0 || $numcommits == 0} return
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
set f0 [lindex $fs 0]
set f1 [lindex $fs 1]
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set y0 [expr {int($f0 * $ymax)}]
set y1 [expr {int($f1 * $ymax)}]
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
if {[info exists targetid]} {
gitk: Fix some corner cases in the targetid/targetrow stuff * Make sure targetrow is never >= numcommits * Don't try to do anything about the target row if the targetid is no longer in the view; it'll just cause Tcl errors * In insertrow, increment targetrow if we are inserting the fake commit at or before the target row * In removerow, if we are removing the target row, make it the next one instead. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-01 23:59:39 +01:00
if {[commitinview $targetid $curview]} {
set r [rowofcommit $targetid]
if {$r != $targetrow} {
# Fix up the scrollregion and change the scrolling position
# now that our target row has moved.
set diff [expr {($r - $targetrow) * $linespc}]
set targetrow $r
setcanvscroll
set ymax [lindex [$canv cget -scrollregion] 3]
incr y0 $diff
incr y1 $diff
set f0 [expr {$y0 / $ymax}]
set f1 [expr {$y1 / $ymax}]
allcanvs yview moveto $f0
$cscroll set $f0 $f1
set need_redisplay 1
}
} else {
unset targetid
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
}
}
set row [expr {int(($y0 - 3) / $linespc) - 1}]
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set endrow [expr {int(($y1 - 3) / $linespc) + 1}]
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
if {$endrow >= $vrowmod($curview)} {
update_arcrows $curview
}
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline ne {} &&
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
$row <= $selectedline && $selectedline <= $endrow} {
set targetrow $selectedline
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
} elseif {[info exists targetid]} {
gitk: Keep the same commits visible as other commits come in Since commits come in out of order and get sorted as we see them, we can have commits coming in and being placed before the commits that are visible in the graph display pane. Previously we just displayed a certain range of row numbers, meaning that when incoming commits were placed before the displayed range, the displayed commits were displaced downwards. This makes it so that we keep the same set of commits displayed, unless the user explicitly scrolls the pane, in which case it scrolls as expected. We do this by having a "target" commit which we try to keep in the same visible position. If commits have come in before it we scroll the canvases by the number of rows that it has moved in the display order. This also fixes a bug in rowofcommit where it would test cached_commitrow before possibly calling update_arcrows, which is where cached_commitrow gets invalidated if things have changed. Now we call update_arcrows if necessary first. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-30 12:41:14 +01:00
set targetrow [expr {int(($row + $endrow) / 2)}]
}
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
if {[info exists targetrow]} {
if {$targetrow >= $numcommits} {
set targetrow [expr {$numcommits - 1}]
}
set targetid [commitonrow $targetrow]
gitk: Fix some corner cases in the targetid/targetrow stuff * Make sure targetrow is never >= numcommits * Don't try to do anything about the target row if the targetid is no longer in the view; it'll just cause Tcl errors * In insertrow, increment targetrow if we are inserting the fake commit at or before the target row * In removerow, if we are removing the target row, make it the next one instead. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-01 23:59:39 +01:00
}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
drawcommits $row $endrow
}
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
proc clear_display {} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global iddrawn linesegs need_redisplay nrows_drawn
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
global vhighlights fhighlights nhighlights rhighlights
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
global linehtag linentag linedtag boldids boldnameids
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
allcanvs delete all
catch {unset iddrawn}
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
catch {unset linesegs}
gitk: Fix "wrong # coordinates" error on reload This fixes the Tk error "wrong # coordinates: expected 0 or 4, got 2" that sometimes occurred when reloading. The problem was that we didn't unset the variables containing the canvas item id numbers for the displayed rows when we cleared the canvases. Thus make_secsel would think it had something to do when it didn't. Thanks to Michele Ballabio for finding a way to trigger the bug reliably. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-19 01:48:45 +02:00
catch {unset linehtag}
catch {unset linentag}
catch {unset linedtag}
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set boldids {}
set boldnameids {}
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
catch {unset vhighlights}
catch {unset fhighlights}
catch {unset nhighlights}
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
catch {unset rhighlights}
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set need_redisplay 0
set nrows_drawn 0
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
proc findcrossings {id} {
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
global rowidlist parentlist numcommits displayorder
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set cross {}
set ccross {}
foreach {s e} [rowranges $id] {
if {$e >= $numcommits} {
set e [expr {$numcommits - 1}]
}
gitk: Make File->Update work properly again If a view is selected it will now just update that view. Also fixed a few other things - if you switch away from a view while gitk is still reading it in, then switch back, gitk will re-read it from scratch. We now re-read the references when switching views. If something was selected before a view change, and we need to read in the new view, we now select the previously-selected commit when we come across it. Fixed a bug in setting of rowrangelist plus a couple of other minor things. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-06 02:18:23 +02:00
if {$e <= $s} continue
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
for {set row $e} {[incr row -1] >= $s} {} {
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set x [lsearch -exact [lindex $rowidlist $row] $id]
if {$x < 0} break
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set olds [lindex $parentlist $row]
set kid [lindex $displayorder $row]
set kidx [lsearch -exact [lindex $rowidlist $row] $kid]
if {$kidx < 0} continue
set nextrow [lindex $rowidlist [expr {$row + 1}]]
foreach p $olds {
set px [lsearch -exact $nextrow $p]
if {$px < 0} continue
if {($kidx < $x && $x < $px) || ($px < $x && $x < $kidx)} {
if {[lsearch -exact $ccross $p] >= 0} continue
if {$x == $px + ($kidx < $px? -1: 1)} {
lappend ccross $p
} elseif {[lsearch -exact $cross $p] < 0} {
lappend cross $p
}
}
}
}
}
return [concat $ccross {{}} $cross]
}
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
proc assigncolor {id} {
gitk: Fix Update menu item This just does the simple thing of resetting everything, reading all the commits, and redoing the whole layout from scratch. Hopefully things are now fast enough that this simple approach is acceptable. Also, this fits in better with future plans for adding the ability to restrict the tree to just a few files and then expand back to the whole tree. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 01:27:12 +01:00
global colormap colors nextcolor
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global parents children children curview
Try to assign colors so crossing lines have different colors In particular try hard to give different colors to lines that cross at a corner in one of the lines.
2005-06-22 11:53:32 +02:00
gitk: Add braces around if expressions Apparently this simplifies things for the parser/compiler and makes it go slightly faster (since without the braces, it potentially has to do two levels of substitutions rather than one). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:10:18 +01:00
if {[info exists colormap($id)]} return
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
set ncolors [llength $colors]
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
if {[info exists children($curview,$id)]} {
set kids $children($curview,$id)
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
} else {
set kids {}
}
if {[llength $kids] == 1} {
set child [lindex $kids 0]
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
if {[info exists colormap($child)]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
&& [llength $parents($curview,$child)] == 1} {
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
set colormap($id) $colormap($child)
return
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
}
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
}
set badcolors {}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set origbad {}
foreach x [findcrossings $id] {
if {$x eq {}} {
# delimiter between corner crossings and other crossings
if {[llength $badcolors] >= $ncolors - 1} break
set origbad $badcolors
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
if {[info exists colormap($x)]
&& [lsearch -exact $badcolors $colormap($x)] < 0} {
lappend badcolors $colormap($x)
Try to assign colors so crossing lines have different colors In particular try hard to give different colors to lines that cross at a corner in one of the lines.
2005-06-22 11:53:32 +02:00
}
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
if {[llength $badcolors] >= $ncolors} {
set badcolors $origbad
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set origbad $badcolors
Try to assign colors so crossing lines have different colors In particular try hard to give different colors to lines that cross at a corner in one of the lines.
2005-06-22 11:53:32 +02:00
if {[llength $badcolors] < $ncolors - 1} {
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
foreach child $kids {
Try to assign colors so crossing lines have different colors In particular try hard to give different colors to lines that cross at a corner in one of the lines.
2005-06-22 11:53:32 +02:00
if {[info exists colormap($child)]
&& [lsearch -exact $badcolors $colormap($child)] < 0} {
lappend badcolors $colormap($child)
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
foreach p $parents($curview,$child) {
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
if {[info exists colormap($p)]
&& [lsearch -exact $badcolors $colormap($p)] < 0} {
lappend badcolors $colormap($p)
Try to assign colors so crossing lines have different colors In particular try hard to give different colors to lines that cross at a corner in one of the lines.
2005-06-22 11:53:32 +02:00
}
}
}
if {[llength $badcolors] >= $ncolors} {
set badcolors $origbad
}
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
}
for {set i 0} {$i <= $ncolors} {incr i} {
set c [lindex $colors $nextcolor]
if {[incr nextcolor] >= $ncolors} {
set nextcolor 0
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
}
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
if {[lsearch -exact $badcolors $c]} break
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
}
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
set colormap($id) $c
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
}
Handle the case of a parent being listed twice in a merge. This happens in the linux-2.6 tree. We draw the graph line double-thick to show that this happened. Also fix a bug where we got a bogus "No commit information available" line at the end on simple repositories like this one.
2005-06-21 02:01:38 +02:00
proc bindline {t id} {
global canv
$canv bind $t <Enter> "lineenter %x %y $id"
$canv bind $t <Motion> "linemotion %x %y $id"
$canv bind $t <Leave> "lineleave $id"
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
$canv bind $t <Button-1> "lineclick %x %y $id 1"
Handle the case of a parent being listed twice in a merge. This happens in the linux-2.6 tree. We draw the graph line double-thick to show that this happened. Also fix a bug where we got a bogus "No commit information available" line at the end on simple repositories like this one.
2005-06-21 02:01:38 +02:00
}
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
proc drawtags {id x xt y1} {
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
global idtags idheads idotherrefs mainhead
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
global linespc lthickness
gitk: Use <Button-2> for context menus on OSX An OSX user has reported that gitk's context menus are not usable under OSX because it doesn't provide a way to generate <Button-3> events. Users can generate <Button-2> events with command+click, so use that for the context menus instead on OSX. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-22 01:11:37 +02:00
global canv rowtextx curview fgcolor bgcolor ctxbut
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
set marks {}
set ntags 0
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
set nheads 0
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
if {[info exists idtags($id)]} {
set marks $idtags($id)
set ntags [llength $marks]
}
if {[info exists idheads($id)]} {
set marks [concat $marks $idheads($id)]
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
set nheads [llength $idheads($id)]
}
if {[info exists idotherrefs($id)]} {
set marks [concat $marks $idotherrefs($id)]
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
}
if {$marks eq {}} {
return $xt
}
set delta [expr {int(0.5 * ($linespc - $lthickness))}]
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set yt [expr {$y1 - 0.5 * $linespc}]
set yb [expr {$yt + $linespc - 1}]
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
set xvals {}
set wvals {}
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
set i -1
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
foreach tag $marks {
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
incr i
if {$i >= $ntags && $i < $ntags + $nheads && $tag eq $mainhead} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set wid [font measure mainfontbold $tag]
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
} else {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set wid [font measure mainfont $tag]
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
}
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
lappend xvals $xt
lappend wvals $wid
set xt [expr {$xt + $delta + $wid + $lthickness + $linespc}]
}
set t [$canv create line $x $y1 [lindex $xvals end] $y1 \
-width $lthickness -fill black -tags tag.$id]
$canv lower $t
foreach tag $marks x $xvals wid $wvals {
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set xl [expr {$x + $delta}]
set xr [expr {$x + $delta + $wid + $lthickness}]
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set font mainfont
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
if {[incr ntags -1] >= 0} {
# draw a tag
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set t [$canv create polygon $x [expr {$yt + $delta}] $xl $yt \
$xr $yt $xr $yb $xl $yb $x [expr {$yb - $delta}] \
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
-width 1 -outline black -fill yellow -tags tag.$id]
$canv bind $t <1> [list showtag $tag 1]
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set rowtextx([rowofcommit $id]) [expr {$xr + $linespc}]
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
} else {
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
# draw a head or other ref
if {[incr nheads -1] >= 0} {
set col green
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
if {$tag eq $mainhead} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set font mainfontbold
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
}
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
} else {
set col "#ddddff"
}
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set xl [expr {$xl - $delta/2}]
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
$canv create polygon $x $yt $xr $yt $xr $yb $x $yb \
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
-width 1 -outline black -fill $col -tags tag.$id
[PATCH] gitk: Add a visual tag for remote refs This patch partly changes the background color for remote refs. It makes it easy to quickly distinguish remote refs from local developer branches. I ignore remote HEADs, as these really should be drawn as aliases to other heads. But there is no simple way to detect that HEADs really are aliases for other refs via "git-ls-remote". Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-18 23:53:07 +02:00
if {[regexp {^(remotes/.*/|remotes/)} $tag match remoteprefix]} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set rwid [font measure mainfont $remoteprefix]
[PATCH] gitk: Add a visual tag for remote refs This patch partly changes the background color for remote refs. It makes it easy to quickly distinguish remote refs from local developer branches. I ignore remote HEADs, as these really should be drawn as aliases to other heads. But there is no simple way to detect that HEADs really are aliases for other refs via "git-ls-remote". Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-18 23:53:07 +02:00
set xi [expr {$x + 1}]
set yti [expr {$yt + 1}]
set xri [expr {$x + $rwid}]
$canv create polygon $xi $yti $xri $yti $xri $yb $xi $yb \
-width 0 -fill "#ffddaa" -tags tag.$id
}
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
}
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
set t [$canv create text $xl $y1 -anchor w -text $tag -fill $fgcolor \
gitk: Show the currently checked-out head in bold font Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-06 02:21:23 +02:00
-font $font -tags [list tag.$id text]]
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
if {$ntags >= 0} {
$canv bind $t <1> [list showtag $tag 1]
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
} elseif {$nheads >= 0} {
gitk: Use <Button-2> for context menus on OSX An OSX user has reported that gitk's context menus are not usable under OSX because it doesn't provide a way to generate <Button-3> events. Users can generate <Button-2> events with command+click, so use that for the context menus instead on OSX. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-22 01:11:37 +02:00
$canv bind $t $ctxbut [list headmenu %X %Y $id $tag]
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
}
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
}
return $xt
}
Compress the graph horizontally if it gets too wide. If the graph gets to use more than a certain percentage (default 50%) of the width of the top-left pane, we now reduce the amount of space allowed for each graph line. This means it doesn't look quite as nice but you can still see the headline for the commit. (Currently the only way to customize the percentage is to edit your ~/.gitk file manually.)
2005-08-05 01:52:16 +02:00
proc xcoord {i level ln} {
global canvx0 xspc1 xspc2
set x [expr {$canvx0 + $i * $xspc1($ln)}]
if {$i > 0 && $i == $level} {
set x [expr {$x + 0.5 * ($xspc2 - $xspc1($ln))}]
} elseif {$i > $level} {
set x [expr {$x + $xspc2 - $xspc1($ln)}]
}
return $x
}
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
proc show_status {msg} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
global canv fgcolor
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
clear_display
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
$canv create text 3 3 -anchor nw -text $msg -font mainfont \
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
-tags text -fill $fgcolor
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
}
Change cursor to a hand cursor when over a SHA1 ID link. This is based on suggestions by Jeff Epler and Linus Torvalds, but extended so that we do the switching between the watch cursor and the normal cursor correctly as well. Also fixed a bug pointed out by Junio Hamano - I wasn't incrementing the link number (duh!).
2005-08-07 07:27:57 +02:00
# Don't change the text pane cursor if it is currently the hand cursor,
# showing that we are over a sha1 ID link.
proc settextcursor {c} {
global ctext curtextcursor
if {[$ctext cget -cursor] == $curtextcursor} {
$ctext config -cursor $c
}
set curtextcursor $c
Restructure to do incremental drawing Some speedups from not doing update so often
2005-06-16 02:27:23 +02:00
}
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
proc nowbusy {what {name {}}} {
global isbusy busyname statusw
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
if {[array names isbusy] eq {}} {
. config -cursor watch
settextcursor watch
}
set isbusy($what) 1
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
set busyname($what) $name
if {$name ne {}} {
$statusw conf -text $name
}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
}
proc notbusy {what} {
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
global isbusy maincursor textcursor busyname statusw
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
catch {
unset isbusy($what)
if {$busyname($what) ne {} &&
[$statusw cget -text] eq $busyname($what)} {
$statusw conf -text {}
}
}
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
if {[array names isbusy] eq {}} {
. config -cursor $maincursor
settextcursor $textcursor
}
}
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
proc findmatches {f} {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
global findtype findstring
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$findtype == [mc "Regexp"]} {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set matches [regexp -indices -all -inline $findstring $f]
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
} else {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set fs $findstring
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$findtype == [mc "IgnCase"]} {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set f [string tolower $f]
set fs [string tolower $fs]
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
set matches {}
set i 0
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set l [string length $fs]
while {[set j [string first $fs $f $i]] >= 0} {
lappend matches [list $j [expr {$j+$l-1}]]
set i [expr {$j + $l}]
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
}
return $matches
}
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
proc dofind {{dirn 1} {wrap 1}} {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
global findstring findstartline findcurline selectedline numcommits
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
global gdttype filehighlight fh_serial find_dirn findallowwrap
Add "Files" and "Pickaxe" to the find menu. "Files" matches the find string against each of the files modified by each commit, and can do exact, case-ignoring or regexp matching. "Pickaxe" uses git-diff-tree -S'string' and can only do exact matching. I called it "pickaxe" rather than "find within patch" since it only finds commits where the string is present in the child but not the parents or vice versa, and "pickaxe" is what the author of that feature calls it.
2005-07-16 13:46:13 +02:00
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
if {[info exists find_dirn]} {
if {$find_dirn == $dirn} return
stopfinding
}
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
focus .
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
if {$findstring eq {} || $numcommits == 0} return
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {}} {
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
set findstartline [lindex [visiblerows] [expr {$dirn < 0}]]
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
} else {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set findstartline $selectedline
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set findcurline $findstartline
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
nowbusy finding [mc "Searching"]
if {$gdttype ne [mc "containing:"] && ![info exists filehighlight]} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
after cancel do_file_hl $fh_serial
do_file_hl $fh_serial
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
}
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
set find_dirn $dirn
set findallowwrap $wrap
run findmore
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
}
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
proc stopfinding {} {
global find_dirn findcurline fprogcoord
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
if {[info exists find_dirn]} {
unset find_dirn
unset findcurline
notbusy finding
set fprogcoord 0
adjustprogress
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
}
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
stopblaming
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
}
proc findmore {} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
global commitdata commitinfo numcommits findpattern findloc
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global findstartline findcurline findallowwrap
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
global find_dirn gdttype fhighlights fprogcoord
gitk: Fix a couple of bugs in the find function First, findmore would sometimes get a Tcl error due to relying on varcorder and vrownum having valid values for the rows being searched, but they may not be valid unless update_arcrows is called, so this makes findmore call update_arcrows if necessary. Secondly, in the "touching paths" and "adding/removing string" modes, findmore was treating fhighlights($row) == -1 as meaning the row matches, whereas it only means that we haven't received an answer from the external git diff-tree process about it yet. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-02 11:44:06 +01:00
global curview varcorder vrownum varccommits vrowmod
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
if {![info exists find_dirn]} {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
return 0
}
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set fldtypes [list [mc "Headline"] [mc "Author"] [mc "Date"] [mc "Committer"] [mc "CDate"] [mc "Comments"]]
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set l $findcurline
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
set moretodo 0
if {$find_dirn > 0} {
incr l
if {$l >= $numcommits} {
set l 0
}
if {$l <= $findstartline} {
set lim [expr {$findstartline + 1}]
} else {
set lim $numcommits
set moretodo $findallowwrap
gitk: Further speedups Now we don't parse the commits as we are reading them, we just put commit data on a list as a blob, and instead parse the commit when we need the various parts of it, such as when a commit is drawn on the canvas. This makes searching a bit more interesting: now we scan through the commit blobs doing a string or regexp match to find commits that might match, then for those that might match, we parse the commit info (if it isn't already parsed) and do the matching for the various fields as before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 12:56:44 +01:00
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
} else {
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
if {$l == 0} {
set l $numcommits
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
}
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
incr l -1
if {$l >= $findstartline} {
set lim [expr {$findstartline - 1}]
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
} else {
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
set lim -1
set moretodo $findallowwrap
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
}
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
set n [expr {($lim - $l) * $find_dirn}]
if {$n > 500} {
set n 500
set moretodo 1
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
}
gitk: Fix a couple of bugs in the find function First, findmore would sometimes get a Tcl error due to relying on varcorder and vrownum having valid values for the rows being searched, but they may not be valid unless update_arcrows is called, so this makes findmore call update_arcrows if necessary. Secondly, in the "touching paths" and "adding/removing string" modes, findmore was treating fhighlights($row) == -1 as meaning the row matches, whereas it only means that we haven't received an answer from the external git diff-tree process about it yet. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-02 11:44:06 +01:00
if {$l + ($find_dirn > 0? $n: 1) > $vrowmod($curview)} {
update_arcrows $curview
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
set found 0
set domore 1
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set ai [bsearch $vrownum($curview) $l]
set a [lindex $varcorder($curview) $ai]
set arow [lindex $vrownum($curview) $ai]
set ids [lindex $varccommits($curview,$a)]
set arowend [expr {$arow + [llength $ids]}]
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {$gdttype eq [mc "containing:"]} {
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
for {} {$n > 0} {incr n -1; incr l $find_dirn} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$l < $arow || $l >= $arowend} {
incr ai $find_dirn
set a [lindex $varcorder($curview) $ai]
set arow [lindex $vrownum($curview) $ai]
set ids [lindex $varccommits($curview,$a)]
set arowend [expr {$arow + [llength $ids]}]
}
set id [lindex $ids [expr {$l - $arow}]]
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
# shouldn't happen unless git log doesn't give all the commits...
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![info exists commitdata($id)] ||
![doesmatch $commitdata($id)]} {
continue
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
if {![info exists commitinfo($id)]} {
getcommit $id
}
set info $commitinfo($id)
foreach f $info ty $fldtypes {
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
if {($findloc eq [mc "All fields"] || $findloc eq $ty) &&
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
[doesmatch $f]} {
set found 1
break
}
}
if {$found} break
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
} else {
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
for {} {$n > 0} {incr n -1; incr l $find_dirn} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {$l < $arow || $l >= $arowend} {
incr ai $find_dirn
set a [lindex $varcorder($curview) $ai]
set arow [lindex $vrownum($curview) $ai]
set ids [lindex $varccommits($curview,$a)]
set arowend [expr {$arow + [llength $ids]}]
}
set id [lindex $ids [expr {$l - $arow}]]
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {![info exists fhighlights($id)]} {
# this sets fhighlights($id) to -1
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
askfilehighlight $l $id
gitk: Fix a couple of bugs in the find function First, findmore would sometimes get a Tcl error due to relying on varcorder and vrownum having valid values for the rows being searched, but they may not be valid unless update_arcrows is called, so this makes findmore call update_arcrows if necessary. Secondly, in the "touching paths" and "adding/removing string" modes, findmore was treating fhighlights($row) == -1 as meaning the row matches, whereas it only means that we haven't received an answer from the external git diff-tree process about it yet. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-02 11:44:06 +01:00
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {$fhighlights($id) > 0} {
gitk: Fix a couple of bugs in the find function First, findmore would sometimes get a Tcl error due to relying on varcorder and vrownum having valid values for the rows being searched, but they may not be valid unless update_arcrows is called, so this makes findmore call update_arcrows if necessary. Secondly, in the "touching paths" and "adding/removing string" modes, findmore was treating fhighlights($row) == -1 as meaning the row matches, whereas it only means that we haven't received an answer from the external git diff-tree process about it yet. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-02 11:44:06 +01:00
set found $domore
break
}
gitk: Index [fnvr]highlights by id rather than row This means that we don't have to keep clearing them out whenever we change the row numbers for some commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-07 12:16:31 +01:00
if {$fhighlights($id) < 0} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
if {$domore} {
set domore 0
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
set findcurline [expr {$l - $find_dirn}]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
}
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
}
}
}
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
if {$found || ($domore && !$moretodo)} {
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
unset findcurline
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
unset find_dirn
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
notbusy finding
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
set fprogcoord 0
adjustprogress
if {$found} {
findselectline $l
} else {
bell
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
return 0
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
if {!$domore} {
flushhighlights
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
} else {
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
set findcurline [expr {$l - $find_dirn}]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
}
gitk: Simplify the code for finding commits This unifies findmore and findmorerev, and adds the ability to do a search with or without wrap around from the end of the list of commits to the beginning (or vice versa for reverse searches). findnext and findprev are gone, and the buttons and keys for searching all call dofind now. dofind doesn't unmark the matches to start with. Shift-up and shift-down are back by popular request, and the searches they do don't wrap around. The other keys that do searches (/, ?, return, M-f) do wrapping searches except for M-g. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-27 13:16:56 +02:00
set n [expr {($findcurline - $findstartline) * $find_dirn - 1}]
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
if {$n < 0} {
incr n $numcommits
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
set fprogcoord [expr {$n * 1.0 / $numcommits}]
adjustprogress
return $domore
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
}
proc findselectline {l} {
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
global findloc commentend ctext findcurline markingmatches gdttype
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
gitk: Highlight only when search type is "containing:". When the search type is "touching paths" or "adding/removing string", it's not very useful to highlight instances of the search string in the commit message, headline or author name, so this disables the highlighting in those cases. This was suggested by Mark Burton <markb@ordern.com>, but the implementation is different to his patch, which tested $gdttype at each place where $markingmatches was tested. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-01 23:02:46 +01:00
set markingmatches [expr {$gdttype eq [mc "containing:"]}]
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
set findcurline $l
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
selectline $l 1
gitk: Highlight only when search type is "containing:". When the search type is "touching paths" or "adding/removing string", it's not very useful to highlight instances of the search string in the commit message, headline or author name, so this disables the highlighting in those cases. This was suggested by Mark Burton <markb@ordern.com>, but the implementation is different to his patch, which tested $gdttype at each place where $markingmatches was tested. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-01 23:02:46 +01:00
if {$markingmatches &&
($findloc eq [mc "All fields"] || $findloc eq [mc "Comments"])} {
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
# highlight the matches in the comments
set f [$ctext get 1.0 $commentend]
set matches [findmatches $f]
foreach match $matches {
set start [lindex $match 0]
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set end [expr {[lindex $match 1] + 1}]
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
$ctext tag add found "1.0 + $start c" "1.0 + $end c"
}
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
}
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
drawvisible
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
# mark the bits of a headline or author that match a find string
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
proc markmatches {canv l str tag matches font row} {
global selectedline
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
set bbox [$canv bbox $tag]
set x0 [lindex $bbox 0]
set y0 [lindex $bbox 1]
set y1 [lindex $bbox 3]
foreach match $matches {
set start [lindex $match 0]
set end [lindex $match 1]
if {$start > $end} continue
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set xoff [font measure $font [string range $str 0 [expr {$start-1}]]]
set xlen [font measure $font [string range $str 0 [expr {$end}]]]
set t [$canv create rect [expr {$x0+$xoff}] $y0 \
[expr {$x0+$xlen+2}] $y1 \
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
-outline {} -tags [list match$l matches] -fill yellow]
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
$canv lower $t
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$row == $selectedline} {
gitk: Fix bugs in the Find function This fixes the problem reported by Brian Downing where searching for a string that doesn't exist would give a Tcl error. The basic problem was that we weren't reading the data for the last commit since it wasn't terminated with a null. This effectively adds a null on the end (if there isn't one already) to make sure we process the last commit. This also makes the yellow background behind instances of the search string appear more consistently, and fixes a bug where the "/" key would just find the same commit again and again instead of advancing. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-26 14:36:39 +02:00
$canv raise $t secsel
}
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
}
}
proc unmarkmatches {} {
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
global markingmatches
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
allcanvs delete matches
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set markingmatches 0
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
stopfinding
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
proc selcanvline {w x y} {
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
global canv canvy0 ctext linespc
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
global rowtextx
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
set ymax [lindex [$canv cget -scrollregion] 3]
Use git-rev-list instead of git-rev-tree. Fix bug in changing font size in entry widgets. Fix bug with B1 click before anything has been drawn. Use "units" and "pages" instead of "u" and "p" for tk8.5.
2005-05-31 14:14:42 +02:00
if {$ymax == {}} return
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
set yfrac [lindex [$canv yview] 0]
set y [expr {$y + $yfrac * $ymax}]
set l [expr {int(($y - $canvy0) / $linespc + 0.5)}]
if {$l < 0} {
set l 0
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
if {$w eq $canv} {
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
set xmax [lindex [$canv cget -scrollregion] 2]
set xleft [expr {[lindex [$canv xview] 0] * $xmax}]
if {![info exists rowtextx($l)] || $xleft + $x < $rowtextx($l)} return
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
unmarkmatches
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
selectline $l 1
Display the list of changed files in a listbox pane.
2005-05-10 03:02:55 +02:00
}
[PATCH] "Child" information in commit window - and cleanups This adds "Child: " lines to the commit window, which tells what children a commit has. It also cleans things up: it marks the text widget as no-wrap, which means that it doesn't need to truncate the commit description arbitrarily by hand. Also, the description itself is now done by a common helper routine that handles both the parent and the children. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-08-09 05:04:20 +02:00
proc commit_descriptor {p} {
global commitinfo
gitk: Fix display of "(...)" for parents/children we haven't drawn In the commit details window, we were displaying "(...)" for the headlines of parents and children that haven't been drawn, without making any attempt to get those headlines. This adds a call to getcommit to commit_descriptor so we get those headlines. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 01:56:08 +02:00
if {![info exists commitinfo($p)]} {
getcommit $p
}
[PATCH] "Child" information in commit window - and cleanups This adds "Child: " lines to the commit window, which tells what children a commit has. It also cleans things up: it marks the text widget as no-wrap, which means that it doesn't need to truncate the commit description arbitrarily by hand. Also, the description itself is now done by a common helper routine that handles both the parent and the children. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-08-09 05:04:20 +02:00
set l "..."
gitk: Fix display of "(...)" for parents/children we haven't drawn In the commit details window, we were displaying "(...)" for the headlines of parents and children that haven't been drawn, without making any attempt to get those headlines. This adds a call to getcommit to commit_descriptor so we get those headlines. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 01:56:08 +02:00
if {[llength $commitinfo($p)] > 1} {
[PATCH] "Child" information in commit window - and cleanups This adds "Child: " lines to the commit window, which tells what children a commit has. It also cleans things up: it marks the text widget as no-wrap, which means that it doesn't need to truncate the commit description arbitrarily by hand. Also, the description itself is now done by a common helper routine that handles both the parent and the children. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-08-09 05:04:20 +02:00
set l [lindex $commitinfo($p) 0]
}
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
return "$p ($l)\n"
[PATCH] "Child" information in commit window - and cleanups This adds "Child: " lines to the commit window, which tells what children a commit has. It also cleans things up: it marks the text widget as no-wrap, which means that it doesn't need to truncate the commit description arbitrarily by hand. Also, the description itself is now done by a common helper routine that handles both the parent and the children. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-08-09 05:04:20 +02:00
}
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
# append some text to the ctext widget, and make any SHA1 ID
# that we know about be a clickable link.
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
proc appendwithlinks {text tags} {
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
global ctext linknum curview
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
set start [$ctext index "end - 1c"]
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
$ctext insert end $text $tags
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
set links [regexp -indices -all -inline {\m[0-9a-f]{6,40}\M} $text]
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
foreach l $links {
set s [lindex $l 0]
set e [lindex $l 1]
set linkid [string range $text $s $e]
incr e
gitk: Fix a couple of bugs insertrow and removerow were trying to adjust rowidlist, rowisopt and rowfinal even if the row where we're inserting/deleting stuff hasn't been laid out yet, which resulted in Tcl errors. This fixes that. Also we weren't deleting the link$linknum tag in appendwithlinks, which resulted in SHA1 IDs in the body of a commit message sometimes getting shown in blue with underlining when they shouldn't. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 02:35:05 +02:00
$ctext tag delete link$linknum
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
$ctext tag add link$linknum "$start + $s c" "$start + $e c"
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
setlink $linkid link$linknum
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
incr linknum
}
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
}
proc setlink {id lk} {
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
global curview ctext pendinglinks
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
set known 0
if {[string length $id] < 40} {
set matches [longid $id]
if {[llength $matches] > 0} {
if {[llength $matches] > 1} return
set known 1
set id [lindex $matches 0]
}
} else {
set known [commitinview $id $curview]
}
if {$known} {
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
$ctext tag conf $lk -foreground blue -underline 1
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
$ctext tag bind $lk <1> [list selbyid $id]
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
$ctext tag bind $lk <Enter> {linkcursor %W 1}
$ctext tag bind $lk <Leave> {linkcursor %W -1}
} else {
lappend pendinglinks($id) $lk
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
interestedin $id {makelink %P}
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
}
}
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
proc appendshortlink {id {pre {}} {post {}}} {
global ctext linknum
$ctext insert end $pre
$ctext tag delete link$linknum
$ctext insert end [string range $id 0 7] link$linknum
$ctext insert end $post
setlink $id link$linknum
incr linknum
}
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
proc makelink {id} {
global pendinglinks
if {![info exists pendinglinks($id)]} return
foreach lk $pendinglinks($id) {
setlink $id $lk
}
unset pendinglinks($id)
}
proc linkcursor {w inc} {
global linkentercount curtextcursor
if {[incr linkentercount $inc] > 0} {
$w configure -cursor hand2
} else {
$w configure -cursor $curtextcursor
if {$linkentercount < 0} {
set linkentercount 0
}
}
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
}
[PATCH] gitk: add key bindings for selecting first and last commit For a keyboard addict like me some keys are still missing from gitk. Especially a key to select a commit when no commit is selected, like just after startup. While we're at it, complete the bindings for moving the view seperately from the selected line. Currently, the up and down keys act on the selected line while pageup and pagedown act on the commits viewed. The idea is to have to normal keys change the selected line: - Home selects first commit - End selects last commit - Up selects previous commit - Down selects next commit - PageUp moves selected line one page up - PageDown moves selected line one page down ...and together with the Control key, it moves the commits view: - Control-Home views first page of commits - Control-End views last page of commits - Control-Up moves commit view one line up - Control-Down moves commit view one line down - Control-PageUp moves commit view one page up - Control-PageDown moves commit view one page down Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl> and with some cleanups and simplifications... Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 02:24:03 +02:00
proc viewnextline {dir} {
global canv linespc
$canv delete hover
set ymax [lindex [$canv cget -scrollregion] 3]
set wnow [$canv yview]
set wtop [expr {[lindex $wnow 0] * $ymax}]
set newtop [expr {$wtop + $dir * $linespc}]
if {$newtop < 0} {
set newtop 0
} elseif {$newtop > $ymax} {
set newtop $ymax
}
allcanvs yview moveto [expr {$newtop * 1.0 / $ymax}]
}
gitk: Show branch name(s) as well, if "show nearby tags" is enabled This is a small extension to the code that reads the complete commit graph, to make it compute descendent heads as well as descendent tags. We don't exclude descendent heads that are descendents of other descendent heads as we do for tags, since it is useful to know all the branches that a commit is on. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-04 03:50:38 +02:00
# add a list of tag or branch names at position pos
# returns the number of names inserted
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
proc appendrefs {pos ids var} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global ctext linknum curview $var maxrefs
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
gitk: Show branch name(s) as well, if "show nearby tags" is enabled This is a small extension to the code that reads the complete commit graph, to make it compute descendent heads as well as descendent tags. We don't exclude descendent heads that are descendents of other descendent heads as we do for tags, since it is useful to know all the branches that a commit is on. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-04 03:50:38 +02:00
if {[catch {$ctext index $pos}]} {
return 0
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
$ctext conf -state normal
$ctext delete $pos "$pos lineend"
set tags {}
foreach id $ids {
foreach tag [set $var\($id\)] {
lappend tags [list $tag $id]
}
}
gitk: Don't try to list large numbers of tags or heads in the details pane With some large repositories, a commit can end up on thousands of branches, which results in an extremely long "Branches:" line in the details window, and that results in the window being extremely slow to scroll. This fixes it by just showing "many (N)" after "Branches:", "Follows:" or "Precedes:", where N is the number of heads or tags. The limit is currently set at 20 but could be made configurable (and the "many" could be a link to pop up a window listing them all in case anyone really wants to know). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:21:57 +02:00
if {[llength $tags] > $maxrefs} {
gitk: Mark forgotten string for translation Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-26 21:13:45 +01:00
$ctext insert $pos "[mc "many"] ([llength $tags])"
gitk: Don't try to list large numbers of tags or heads in the details pane With some large repositories, a commit can end up on thousands of branches, which results in an extremely long "Branches:" line in the details window, and that results in the window being extremely slow to scroll. This fixes it by just showing "many (N)" after "Branches:", "Follows:" or "Precedes:", where N is the number of heads or tags. The limit is currently set at 20 but could be made configurable (and the "many" could be a link to pop up a window listing them all in case anyone really wants to know). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:21:57 +02:00
} else {
set tags [lsort -index 0 -decreasing $tags]
set sep {}
foreach ti $tags {
set id [lindex $ti 1]
set lk link$linknum
incr linknum
$ctext tag delete $lk
$ctext insert $pos $sep
$ctext insert $pos [lindex $ti 0] $lk
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
setlink $id $lk
gitk: Don't try to list large numbers of tags or heads in the details pane With some large repositories, a commit can end up on thousands of branches, which results in an extremely long "Branches:" line in the details window, and that results in the window being extremely slow to scroll. This fixes it by just showing "many (N)" after "Branches:", "Follows:" or "Precedes:", where N is the number of heads or tags. The limit is currently set at 20 but could be made configurable (and the "many" could be a link to pop up a window listing them all in case anyone really wants to know). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:21:57 +02:00
set sep ", "
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
$ctext conf -state disabled
gitk: Show branch name(s) as well, if "show nearby tags" is enabled This is a small extension to the code that reads the complete commit graph, to make it compute descendent heads as well as descendent tags. We don't exclude descendent heads that are descendents of other descendent heads as we do for tags, since it is useful to know all the branches that a commit is on. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-04 03:50:38 +02:00
return [llength $tags]
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
# called when we have finished computing the nearby tags
proc dispneartags {delay} {
global selectedline currentid showneartags tagphase
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {} || !$showneartags} return
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
after cancel dispnexttag
if {$delay} {
after 200 dispnexttag
set tagphase -1
} else {
after idle dispnexttag
set tagphase 0
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
proc dispnexttag {} {
global selectedline currentid showneartags tagphase ctext
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {} || !$showneartags} return
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
switch -- $tagphase {
0 {
set dtags [desctags $currentid]
if {$dtags ne {}} {
appendrefs precedes $dtags idtags
}
}
1 {
set atags [anctags $currentid]
if {$atags ne {}} {
appendrefs follows $atags idtags
}
}
2 {
set dheads [descheads $currentid]
if {$dheads ne {}} {
if {[appendrefs branch $dheads idheads] > 1
&& [$ctext get "branch -3c"] eq "h"} {
# turn "Branch" into "Branches"
$ctext conf -state normal
$ctext insert "branch -2c" "es"
$ctext conf -state disabled
}
}
gitk: Show branch name(s) as well, if "show nearby tags" is enabled This is a small extension to the code that reads the complete commit graph, to make it compute descendent heads as well as descendent tags. We don't exclude descendent heads that are descendents of other descendent heads as we do for tags, since it is useful to know all the branches that a commit is on. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-04 03:50:38 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {[incr tagphase] <= 2} {
after idle dispnexttag
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
}
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
proc make_secsel {id} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global linehtag linentag linedtag canv canv2 canv3
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
if {![info exists linehtag($id)]} return
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
$canv delete secsel
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set t [eval $canv create rect [$canv bbox $linehtag($id)] -outline {{}} \
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
-tags secsel -fill [$canv cget -selectbackground]]
$canv lower $t
$canv2 delete secsel
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set t [eval $canv2 create rect [$canv2 bbox $linentag($id)] -outline {{}} \
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
-tags secsel -fill [$canv2 cget -selectbackground]]
$canv2 lower $t
$canv3 delete secsel
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set t [eval $canv3 create rect [$canv3 bbox $linedtag($id)] -outline {{}} \
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
-tags secsel -fill [$canv3 cget -selectbackground]]
$canv3 lower $t
}
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
proc make_idmark {id} {
global linehtag canv fgcolor
if {![info exists linehtag($id)]} return
$canv delete markid
set t [eval $canv create rect [$canv bbox $linehtag($id)] \
-tags markid -outline $fgcolor]
$canv raise $t
}
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
proc selectline {l isnew {desired_loc {}}} {
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
global canv ctext commitinfo selectedline
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global canvy0 linespc parents children curview
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
global currentid sha1entry
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
global commentend idtags linknum
gitk: Make File->Update work properly again If a view is selected it will now just update that view. Also fixed a few other things - if you switch away from a view while gitk is still reading it in, then switch back, gitk will re-read it from scratch. We now re-read the references when switching views. If something was selected before a view change, and we need to read in the new view, we now select the previously-selected commit when we come across it. Fixed a bug in setting of rowrangelist plus a couple of other minor things. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-06 02:18:23 +02:00
global mergemax numcommits pending_select
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
global cmitmode showneartags allcommits
gitk: Fix problem with target row not being in scroll region Since we limit the rate at which we do updates to the canvas scrolling regions, it's possible to get into selectline for a row that is outside the currently-set scrolling region. When this happens, selectline can't scroll to show the selected line, and as a consequence, drawvisible chooses some other bogus row to be the target row. This fixes it by calling setcanvscroll from selectline in this case. We also set selectedline (and currentid) before calling drawvisible so that drawvisible makes the right choice of target row. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-07 12:51:55 +01:00
global targetrow targetid lastscrollrows
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
global autoselect jump_to_here
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
gitk: Make File->Update work properly again If a view is selected it will now just update that view. Also fixed a few other things - if you switch away from a view while gitk is still reading it in, then switch back, gitk will re-read it from scratch. We now re-read the references when switching views. If something was selected before a view change, and we need to read in the new view, we now select the previously-selected commit when we come across it. Fixed a bug in setting of rowrangelist plus a couple of other minor things. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-06 02:18:23 +02:00
catch {unset pending_select}
Draw graph lines as one continuous line where possible Added context menu on lines Added headline display when the mouse hovers over a line Removed some debug messages
2005-06-17 02:12:26 +02:00
$canv delete hover
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
normalline
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
unsel_reflist
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
stopfinding
gitk: Various speed improvements This rearranges the code a little to eliminate some procedure calls and reduce the number of globals accessed. It makes rowidlist and rowoffsets lists rather than arrays, and removes the lineid array, since $lineid($l) was the same as [lindex $displayorder $l], and the latter is a little faster. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 12:10:19 +01:00
if {$l < 0 || $l >= $numcommits} return
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
set id [commitonrow $l]
set targetid $id
set targetrow $l
gitk: Fix problem with target row not being in scroll region Since we limit the rate at which we do updates to the canvas scrolling regions, it's possible to get into selectline for a row that is outside the currently-set scrolling region. When this happens, selectline can't scroll to show the selected line, and as a consequence, drawvisible chooses some other bogus row to be the target row. This fixes it by calling setcanvscroll from selectline in this case. We also set selectedline (and currentid) before calling drawvisible so that drawvisible makes the right choice of target row. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-07 12:51:55 +01:00
set selectedline $l
set currentid $id
if {$lastscrollrows < $numcommits} {
setcanvscroll
}
gitk: Fix problems with target row stuff Occasionally the target row stuff would scroll the display to some uninteresting commit while reading. There were two problems: one was that drawvisible would set targetrow even if there was no target previously and no row selected, and the other was that it was possible for the target row to get pushed down past numcommits, if drawvisible was called after rows were added but before layoutmore got run. The first problem is fixed by just not setting targetrow/id unless there is a selected row or they were set previously. The second problem is fixed by updating numcommits immediately new rows are added. This leads to a simplification of layoutmore and chewcommits but also means that some of the things that were done in layoutmore now need to be done elsewhere, since layoutmore can no longer use numcommits to know how much it has seen previously. Hence the changes to getcommits, initlayout and setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:11:08 +01:00
Display the list of changed files in a listbox pane.
2005-05-10 03:02:55 +02:00
set y [expr {$canvy0 + $l * $linespc}]
More fixes for geometry restoration Make up/down/pgup/pgdn work again Return in find string entry does find Scale circles and lines with font size Fix scrolling to make entire selected line visible Use white circle for commits not listed but put in to terminate lines Fix diff parsing for created and deleted files
2005-05-19 00:51:00 +02:00
set ymax [lindex [$canv cget -scrollregion] 3]
Handle \ No newline at end of line lines in diff Put (deleted) or (created, mode xxx) in header lines Fix scrolling to bring lines on screen
2005-05-19 12:56:42 +02:00
set ytop [expr {$y - $linespc - 1}]
set ybot [expr {$y + $linespc + 1}]
Display the list of changed files in a listbox pane.
2005-05-10 03:02:55 +02:00
set wnow [$canv yview]
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set wtop [expr {[lindex $wnow 0] * $ymax}]
set wbot [expr {[lindex $wnow 1] * $ymax}]
Handle \ No newline at end of line lines in diff Put (deleted) or (created, mode xxx) in header lines Fix scrolling to bring lines on screen
2005-05-19 12:56:42 +02:00
set wh [expr {$wbot - $wtop}]
set newtop $wtop
More fixes for geometry restoration Make up/down/pgup/pgdn work again Return in find string entry does find Scale circles and lines with font size Fix scrolling to make entire selected line visible Use white circle for commits not listed but put in to terminate lines Fix diff parsing for created and deleted files
2005-05-19 00:51:00 +02:00
if {$ytop < $wtop} {
Handle \ No newline at end of line lines in diff Put (deleted) or (created, mode xxx) in header lines Fix scrolling to bring lines on screen
2005-05-19 12:56:42 +02:00
if {$ybot < $wtop} {
set newtop [expr {$y - $wh / 2.0}]
} else {
set newtop $ytop
if {$newtop > $wtop - $linespc} {
set newtop [expr {$wtop - $linespc}]
}
More fixes for geometry restoration Make up/down/pgup/pgdn work again Return in find string entry does find Scale circles and lines with font size Fix scrolling to make entire selected line visible Use white circle for commits not listed but put in to terminate lines Fix diff parsing for created and deleted files
2005-05-19 00:51:00 +02:00
}
Handle \ No newline at end of line lines in diff Put (deleted) or (created, mode xxx) in header lines Fix scrolling to bring lines on screen
2005-05-19 12:56:42 +02:00
} elseif {$ybot > $wbot} {
if {$ytop > $wbot} {
set newtop [expr {$y - $wh / 2.0}]
} else {
set newtop [expr {$ybot - $wh}]
if {$newtop < $wtop + $linespc} {
set newtop [expr {$wtop + $linespc}]
}
More fixes for geometry restoration Make up/down/pgup/pgdn work again Return in find string entry does find Scale circles and lines with font size Fix scrolling to make entire selected line visible Use white circle for commits not listed but put in to terminate lines Fix diff parsing for created and deleted files
2005-05-19 00:51:00 +02:00
}
Handle \ No newline at end of line lines in diff Put (deleted) or (created, mode xxx) in header lines Fix scrolling to bring lines on screen
2005-05-19 12:56:42 +02:00
}
if {$newtop != $wtop} {
if {$newtop < 0} {
set newtop 0
}
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
allcanvs yview moveto [expr {$newtop * 1.0 / $ymax}]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
drawvisible
Display the list of changed files in a listbox pane.
2005-05-10 03:02:55 +02:00
}
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
make_secsel $id
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
if {$isnew} {
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
addtohistory [list selbyid $id]
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
}
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
$sha1entry delete 0 end
$sha1entry insert 0 $id
[PATCH] gitk: make autoselect optional Whenever a commit is selected in the graph pane, its SHA1 is automatically put into the selection buffer for cut and paste. However, some users may find this behavior annoying since it can overwrite something they actually wanted to keep in the buffer. This makes the behavior optional under the name "Auto-select SHA1", but continues to default to "on". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-06 12:49:25 +01:00
if {$autoselect} {
$sha1entry selection from 0
$sha1entry selection to end
}
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
rhighlight_sel $id
Add a widget to show the SHA1 ID of the current commit Add a find facility to search within the commits Cope with multiple starting points.
2005-05-15 07:56:51 +02:00
Display the list of changed files in a listbox pane.
2005-05-10 03:02:55 +02:00
$ctext conf -state normal
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
clear_ctext
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
set linknum 0
gitk: Avoid a crash in selectline if commitinfo($id) isn't set Occasionally I see a crash in selectline with commitinfo($id) not set. This makes sure it is set by calling getcommit $id if it isn't. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-07 11:19:18 +01:00
if {![info exists commitinfo($id)]} {
getcommit $id
}
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
set info $commitinfo($id)
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set date [formatdate [lindex $info 2]]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "[mc "Author"]: [lindex $info 1] $date\n"
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set date [formatdate [lindex $info 4]]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "[mc "Committer"]: [lindex $info 3] $date\n"
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
if {[info exists idtags($id)]} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end [mc "Tags:"]
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
foreach tag $idtags($id) {
$ctext insert end " $tag"
}
$ctext insert end "\n"
}
[PATCH] gitk - remove trailing whitespace from a few lines. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:44:46 +01:00
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
set headers {}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set olds $parents($curview,$id)
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
if {[llength $olds] > 1} {
gitk: Use git-diff-tree --cc for showing the diffs for merges This replaces a lot of code that used the result from several 2-way diffs to generate a combined diff for a merge. Now we just use git-diff-tree --cc and colorize the output a bit, which is a lot simpler, and has the enormous advantage that if the diff doesn't show quite what someone thinks it should show, I can deflect the blame to someone else. :) Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:13:52 +01:00
set np 0
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
foreach p $olds {
gitk: Use git-diff-tree --cc for showing the diffs for merges This replaces a lot of code that used the result from several 2-way diffs to generate a combined diff for a merge. Now we just use git-diff-tree --cc and colorize the output a bit, which is a lot simpler, and has the enormous advantage that if the diff doesn't show quite what someone thinks it should show, I can deflect the blame to someone else. :) Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:13:52 +01:00
if {$np >= $mergemax} {
set tag mmax
} else {
set tag m$np
}
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "[mc "Parent"]: " $tag
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
appendwithlinks [commit_descriptor $p] {}
gitk: Use git-diff-tree --cc for showing the diffs for merges This replaces a lot of code that used the result from several 2-way diffs to generate a combined diff for a merge. Now we just use git-diff-tree --cc and colorize the output a bit, which is a lot simpler, and has the enormous advantage that if the diff doesn't show quite what someone thinks it should show, I can deflect the blame to someone else. :) Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:13:52 +01:00
incr np
}
} else {
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
foreach p $olds {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
append headers "[mc "Parent"]: [commit_descriptor $p]"
[PATCH] "Child" information in commit window - and cleanups This adds "Child: " lines to the commit window, which tells what children a commit has. It also cleans things up: it marks the text widget as no-wrap, which means that it doesn't need to truncate the commit description arbitrarily by hand. Also, the description itself is now done by a common helper routine that handles both the parent and the children. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-08-09 05:04:20 +02:00
}
}
gitk: Use git-diff-tree --cc for showing the diffs for merges This replaces a lot of code that used the result from several 2-way diffs to generate a combined diff for a merge. Now we just use git-diff-tree --cc and colorize the output a bit, which is a lot simpler, and has the enormous advantage that if the diff doesn't show quite what someone thinks it should show, I can deflect the blame to someone else. :) Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-06 23:13:52 +01:00
gitk: Get rid of the childlist variable The information in childlist is a duplicate of what's in the children array, and it wasn't being accessed often enough to be really worth keeping the list around as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-18 01:48:23 +02:00
foreach c $children($curview,$id) {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
append headers "[mc "Child"]: [commit_descriptor $c]"
[PATCH] gitk "parent information" in commit window This adds a useful "Parent:" line to the git commit information window. It looks something like this (from the infamous octopus merge): Author: Junio C Hamano <junkio@cox.net> 2005-05-05 16:16:54 Committer: Junio C Hamano <junkio@cox.net> 2005-05-05 16:16:54 Parent: fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc (Update git-apply-patch-script ...) Parent: 9e30dd7c0ecc9f10372f31539d0122db97418353 (Make git-prune-script executa ...) Parent: c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a (Do not write out new index if ...) Parent: 660265909fc178581ef327076716dfd3550e6e7b (diff-cache shows differences ...) Parent: b28858bf65d4fd6d8bb070865518ec43817fe7f3 (Update diff engine for symlin ...) Octopus merge of the following five patches. Update git-apply-patch-script for symbolic links. Make git-prune-script executable again. Do not write out new index if nothing has changed. diff-cache shows differences for unmerged paths without --cache. Update diff engine for symlinks stored in the cache. Signed-off-by: Junio C Hamano <junkio@cox.net> where all the parent commit ID's are clickable, because the new lines are added as part of the "comment" string, and thus the regular clickability thing will match them automatically. I think this is good. And my random-tcl-monkey-skills are clearly getting better (although it's perfectly possible that somebody who actually knows what he is doing would have done things differently). Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-08-07 22:58:56 +02:00
}
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
# make anything that looks like a SHA1 ID be a clickable link
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
appendwithlinks $headers {}
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
if {$showneartags} {
if {![info exists allcommits]} {
getallcommits
}
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "[mc "Branch"]: "
gitk: Show branch name(s) as well, if "show nearby tags" is enabled This is a small extension to the code that reads the complete commit graph, to make it compute descendent heads as well as descendent tags. We don't exclude descendent heads that are descendents of other descendent heads as we do for tags, since it is useful to know all the branches that a commit is on. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-04 03:50:38 +02:00
$ctext mark set branch "end -1c"
$ctext mark gravity branch left
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "\n[mc "Follows"]: "
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
$ctext mark set follows "end -1c"
$ctext mark gravity follows left
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "\n[mc "Precedes"]: "
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
$ctext mark set precedes "end -1c"
$ctext mark gravity precedes left
$ctext insert end "\n"
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
dispneartags 1
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
$ctext insert end "\n"
gitk: Cope with commit messages with carriage-returns and initial blank lines In some repositories imported from other systems we can get carriage return characters in the commit message, which leads to a multi-line headline being displayed in the summary window, which looks bad. Also some commit messages start with one or more blank lines, which leads to an empty headline. This fixes these problems. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 02:56:02 +02:00
set comment [lindex $info 5]
if {[string first "\r" $comment] >= 0} {
set comment [string map {"\r" "\n "} $comment]
}
appendwithlinks $comment {comment}
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
$ctext tag remove found 1.0 end
Display the list of changed files in a listbox pane.
2005-05-10 03:02:55 +02:00
$ctext conf -state disabled
Error popups on error conditions rather than stderr msgs Stop . bindings firing on find string entry keypresses Fix geometry saving/restoring a bit Show the terminal commits Highlight comment matches in the comment window
2005-05-18 01:23:07 +02:00
set commentend [$ctext index "end - 1c"]
Display the list of changed files in a listbox pane.
2005-05-10 03:02:55 +02:00
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
set jump_to_here $desired_loc
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
init_flist [mc "Comments"]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
if {$cmitmode eq "tree"} {
gettree $id
} elseif {[llength $olds] <= 1} {
gitk: Fix diff this->selected and selected->this functions The change in 8b7e5d76e836396a097bb6f61cf930ea872a7bd3, which makes a couple of git-diff-tree calls supply only one id rather than two, fixes the display when showing what a single commit did with dense revlists, but broke the diff this->selected and diff selected->this right-click menu functions. Yann Dirson pointed this out and had a patch that fixed the diff menu functions by passing a "singlecommit" flag around. This fixes it a bit differently, by making the ids and diffids variables be either a single id, in the case of showing what a commit did, or {oldid newid}, in the case of the diff menu functions. That way we can just pass $ids to git-diff-tree as is. Most of the changes in fact are just reversing the order of ids in $ids and $diffids, because they used to be {child parent}, but git-diff-tree requires old id before new id. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-28 10:41:56 +01:00
startdiff $id
gitk: Show diffs for boundary commits With this we run git-diff-tree on a commit even if we think it has no parents, either because it really has no parents or because it is a boundary commit. This means that gitk shows the diff for a boundary commit when it is selected. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-30 11:50:40 +02:00
} else {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
mergediff $id
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
}
}
[PATCH] gitk: add key bindings for selecting first and last commit For a keyboard addict like me some keys are still missing from gitk. Especially a key to select a commit when no commit is selected, like just after startup. While we're at it, complete the bindings for moving the view seperately from the selected line. Currently, the up and down keys act on the selected line while pageup and pagedown act on the commits viewed. The idea is to have to normal keys change the selected line: - Home selects first commit - End selects last commit - Up selects previous commit - Down selects next commit - PageUp moves selected line one page up - PageDown moves selected line one page down ...and together with the Control key, it moves the commits view: - Control-Home views first page of commits - Control-End views last page of commits - Control-Up moves commit view one line up - Control-Down moves commit view one line down - Control-PageUp moves commit view one page up - Control-PageDown moves commit view one page down Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl> and with some cleanups and simplifications... Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 02:24:03 +02:00
proc selfirstline {} {
unmarkmatches
selectline 0 1
}
proc sellastline {} {
global numcommits
unmarkmatches
set l [expr {$numcommits - 1}]
selectline $l 1
}
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
proc selnextline {dir} {
global selectedline
[PATCH] gitk: Enable selected patch text on Windows On windows, mouse input follows the keyboard focus, so to allow selecting text from the patch canvas we must not shift focus back to the top level. This change has no negative impact on X, so we don't explicitly test for Win32 on this change. This provides similar selection capability as already available using X-Windows. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-08 03:40:34 +02:00
focus .
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {}} return
[PATCH] gitk: put braces around exprs This braces all exprs. It just seemed to be a few that were missed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-23 02:39:53 +01:00
set l [expr {$selectedline + $dir}]
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
unmarkmatches
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
selectline $l 1
}
[PATCH] gitk: add key bindings for selecting first and last commit For a keyboard addict like me some keys are still missing from gitk. Especially a key to select a commit when no commit is selected, like just after startup. While we're at it, complete the bindings for moving the view seperately from the selected line. Currently, the up and down keys act on the selected line while pageup and pagedown act on the commits viewed. The idea is to have to normal keys change the selected line: - Home selects first commit - End selects last commit - Up selects previous commit - Down selects next commit - PageUp moves selected line one page up - PageDown moves selected line one page down ...and together with the Control key, it moves the commits view: - Control-Home views first page of commits - Control-End views last page of commits - Control-Up moves commit view one line up - Control-Down moves commit view one line down - Control-PageUp moves commit view one page up - Control-PageDown moves commit view one page down Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl> and with some cleanups and simplifications... Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 02:24:03 +02:00
proc selnextpage {dir} {
global canv linespc selectedline numcommits
set lpp [expr {([winfo height $canv] - 2) / $linespc}]
if {$lpp < 1} {
set lpp 1
}
allcanvs yview scroll [expr {$dir * $lpp}] units
gitk: Fix bug where page-up/down wouldn't always work properly If the user pressed page up or page down and the new page wasn't already drawn, we failed to select the line we wanted in the new page. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:58:49 +02:00
drawvisible
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {}} return
[PATCH] gitk: add key bindings for selecting first and last commit For a keyboard addict like me some keys are still missing from gitk. Especially a key to select a commit when no commit is selected, like just after startup. While we're at it, complete the bindings for moving the view seperately from the selected line. Currently, the up and down keys act on the selected line while pageup and pagedown act on the commits viewed. The idea is to have to normal keys change the selected line: - Home selects first commit - End selects last commit - Up selects previous commit - Down selects next commit - PageUp moves selected line one page up - PageDown moves selected line one page down ...and together with the Control key, it moves the commits view: - Control-Home views first page of commits - Control-End views last page of commits - Control-Up moves commit view one line up - Control-Down moves commit view one line down - Control-PageUp moves commit view one page up - Control-PageDown moves commit view one page down Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl> and with some cleanups and simplifications... Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 02:24:03 +02:00
set l [expr {$selectedline + $dir * $lpp}]
if {$l < 0} {
set l 0
} elseif {$l >= $numcommits} {
set l [expr $numcommits - 1]
}
unmarkmatches
[PATCH] gitk - remove trailing whitespace from a few lines. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:44:46 +01:00
selectline $l 1
[PATCH] gitk: add key bindings for selecting first and last commit For a keyboard addict like me some keys are still missing from gitk. Especially a key to select a commit when no commit is selected, like just after startup. While we're at it, complete the bindings for moving the view seperately from the selected line. Currently, the up and down keys act on the selected line while pageup and pagedown act on the commits viewed. The idea is to have to normal keys change the selected line: - Home selects first commit - End selects last commit - Up selects previous commit - Down selects next commit - PageUp moves selected line one page up - PageDown moves selected line one page down ...and together with the Control key, it moves the commits view: - Control-Home views first page of commits - Control-End views last page of commits - Control-Up moves commit view one line up - Control-Down moves commit view one line down - Control-PageUp moves commit view one page up - Control-PageDown moves commit view one page down Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl> and with some cleanups and simplifications... Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-05 02:24:03 +02:00
}
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
proc unselectline {} {
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
global selectedline currentid
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
set selectedline {}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
catch {unset currentid}
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
allcanvs delete secsel
gitk: Provide ability to highlight based on relationship to selected commit This provides a way to highlight commits that are, or are not, descendents or ancestors of the currently selected commit. It's still rough around the edges but seems to be useful even so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-29 11:50:02 +02:00
rhighlight_none
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
}
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
proc reselectline {} {
global selectedline
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline ne {}} {
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
selectline $selectedline 0
}
}
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
proc addtohistory {cmd} {
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
global history historyindex curview
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
set elt [list $curview $cmd]
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
if {$historyindex > 0
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
&& [lindex $history [expr {$historyindex - 1}]] == $elt} {
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
return
}
if {$historyindex < [llength $history]} {
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
set history [lreplace $history $historyindex end $elt]
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
} else {
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
lappend history $elt
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
}
incr historyindex
if {$historyindex > 1} {
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.bar.leftbut conf -state normal
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
} else {
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.bar.leftbut conf -state disabled
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
}
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.bar.rightbut conf -state disabled
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
}
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
proc godo {elt} {
global curview
set view [lindex $elt 0]
set cmd [lindex $elt 1]
if {$curview != $view} {
showview $view
}
eval $cmd
}
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
proc goback {} {
global history historyindex
[PATCH] gitk: Enable selected patch text on Windows On windows, mouse input follows the keyboard focus, so to allow selecting text from the patch canvas we must not shift focus back to the top level. This change has no negative impact on X, so we don't explicitly test for Win32 on this change. This provides similar selection capability as already available using X-Windows. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-08 03:40:34 +02:00
focus .
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
if {$historyindex > 1} {
incr historyindex -1
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
godo [lindex $history [expr {$historyindex - 1}]]
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.bar.rightbut conf -state normal
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
}
if {$historyindex <= 1} {
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.bar.leftbut conf -state disabled
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
}
}
proc goforw {} {
global history historyindex
[PATCH] gitk: Enable selected patch text on Windows On windows, mouse input follows the keyboard focus, so to allow selecting text from the patch canvas we must not shift focus back to the top level. This change has no negative impact on X, so we don't explicitly test for Win32 on this change. This provides similar selection capability as already available using X-Windows. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-08 03:40:34 +02:00
focus .
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
if {$historyindex < [llength $history]} {
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
set cmd [lindex $history $historyindex]
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
incr historyindex
gitk: Remember the view in the history list When moving backwards or forwards through the history list, this automatically switches the view so that each point that we jump to is shown in the same view that it was originally displayed in. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-21 02:35:31 +02:00
godo $cmd
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.bar.leftbut conf -state normal
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
}
if {$historyindex >= [llength $history]} {
[PATCH] Make gitk work reasonably well on Cygwin. The gitk gui layout was completely broken on Cygwin. If gitk was started without previous geometry in ~/.gitk, the user could drag the window sashes to get a useable layout. However, if ~/.gitk existed, this was not possible at all. The fix was to rewrite makewindow, changing the toplevel containers and the particular geometry information saved between sessions. Numerous bugs in both the Cygwin and the Linux Tk versions make this a delicate balancing act: the version here works in both but many subtle variants are competely broken in one or the other environment. Three user visible changes result: 1 - The viewer is fully functional under Cygwin. 2 - The search bar moves from the bottom to the top of the lower left pane. This was necessary to get around a layout problem on Cygwin. 3 - The window size and position is saved and restored between sessions. Again, this is necessary to get around a layout problem on Cygwin. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-01 14:46:38 +01:00
.tf.bar.rightbut conf -state disabled
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
}
First cut at displaying the diffs for a merge. We display the files where the child differs from the first parent first in black in the file list window, followed by the second parent in blue, and so on using different colors for each parent (provided you don't have more than 6 parents; if you do we cycle around).
2005-07-17 09:39:44 +02:00
}
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
proc gettree {id} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
global treefilelist treeidlist diffids diffmergeid treepending
global nullid nullid2
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
set diffids $id
catch {unset diffmergeid}
if {![info exists treefilelist($id)]} {
if {![info exists treepending]} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
if {$id eq $nullid} {
set cmd [list | git ls-files]
} elseif {$id eq $nullid2} {
set cmd [list | git ls-files --stage -t]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
} else {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set cmd [list | git ls-tree -r $id]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
if {[catch {set gtf [open $cmd r]}]} {
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
return
}
set treepending $id
set treefilelist($id) {}
set treeidlist($id) {}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
fconfigure $gtf -blocking 0 -encoding binary
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
filerun $gtf [list gettreeline $gtf $id]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
} else {
setfilelist $id
}
}
proc gettreeline {gtf id} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
global treefilelist treeidlist treepending cmitmode diffids nullid nullid2
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set nl 0
while {[incr nl] <= 1000 && [gets $gtf line] >= 0} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
if {$diffids eq $nullid} {
set fname $line
} else {
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
set i [string first "\t" $line]
if {$i < 0} continue
set fname [string range $line [expr {$i+1}] end]
gitk: Fix handling of tree file list with special chars in names Alex Riesen pointed out that displaying a commit in 'tree' mode fails if some files have names with special characters such as '{' or '}' in them, due to the fact that we treat the line returned from git ls-tree as a Tcl list at one point. This fixes it by doing what I originally intended but didn't quite get right. We split the line from git ls-tree at the first tab and treat the part before the tab as a list (which is OK since it doesn't have special characters in it) and the part after the tab as the filename. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-28 01:40:50 +02:00
set line [string range $line 0 [expr {$i-1}]]
if {$diffids ne $nullid2 && [lindex $line 1] ne "blob"} continue
set sha1 [lindex $line 2]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
lappend treeidlist($id) $sha1
}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
set fname [encoding convertfrom $fname]
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
lappend treefilelist($id) $fname
}
if {![eof $gtf]} {
return [expr {$nl >= 1000? 2: 1}]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
close $gtf
unset treepending
if {$cmitmode ne "tree"} {
if {![info exists diffmergeid]} {
gettreediffs $diffids
}
} elseif {$id ne $diffids} {
gettree $diffids
} else {
setfilelist $id
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
proc showfile {f} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
global treefilelist treeidlist diffids nullid nullid2
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
global ctext_file_names ctext_file_lines
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
global ctext commentend
set i [lsearch -exact $treefilelist($diffids) $f]
if {$i < 0} {
puts "oops, $f not in list for id $diffids"
return
}
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
if {$diffids eq $nullid} {
if {[catch {set bf [open $f r]} err]} {
puts "oops, can't read $f: $err"
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
return
}
} else {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set blob [lindex $treeidlist($diffids) $i]
if {[catch {set bf [open [concat | git cat-file blob $blob] r]} err]} {
puts "oops, error reading blob $blob: $err"
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
return
}
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
fconfigure $bf -blocking 0 -encoding [get_path_encoding $f]
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
filerun $bf [list getblobline $bf $diffids]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
$ctext config -state normal
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
clear_ctext $commentend
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
lappend ctext_file_names $f
lappend ctext_file_lines [lindex [split $commentend "."] 0]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
$ctext insert end "\n"
$ctext insert end "$f\n" filesep
$ctext config -state disabled
$ctext yview $commentend
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
settabs 0
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
proc getblobline {bf id} {
global diffids cmitmode ctext
if {$id ne $diffids || $cmitmode ne "tree"} {
catch {close $bf}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
$ctext config -state normal
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set nl 0
while {[incr nl] <= 1000 && [gets $bf line] >= 0} {
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
$ctext insert end "$line\n"
}
if {[eof $bf]} {
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
global jump_to_here ctext_file_names commentend
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
# delete last newline
$ctext delete "end - 2c" "end - 1c"
close $bf
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
if {$jump_to_here ne {} &&
[lindex $jump_to_here 0] eq [lindex $ctext_file_names 0]} {
set lnum [expr {[lindex $jump_to_here 1] +
[lindex [split $commentend .] 0]}]
mark_ctext_line $lnum
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
$ctext config -state disabled
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return [expr {$nl >= 1000? 2: 1}]
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
}
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
proc mark_ctext_line {lnum} {
gitk: Make the background color of marked lines configurable This makes it possible for the user to configure the background color of lines that are "marked". At the moment only the "show the origin of this line" function marks lines. This also makes the user's choice persistent by saving it in ~/.gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 12:37:21 +01:00
global ctext markbgcolor
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
$ctext tag delete omark
$ctext tag add omark $lnum.0 "$lnum.0 + 1 line"
gitk: Make the background color of marked lines configurable This makes it possible for the user to configure the background color of lines that are "marked". At the moment only the "show the origin of this line" function marks lines. This also makes the user's choice persistent by saving it in ~/.gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 12:37:21 +01:00
$ctext tag conf omark -background $markbgcolor
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
$ctext see $lnum.0
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
proc mergediff {id} {
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
global diffmergeid
gitk: Fix file list context menu for merge commits Currently it displays an ugly error box, because the treediffs array is not filled for such commits. This fixes it by making getmergediffline add the filenames it sees to the treediffs array like gettreediffline does. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-08 09:05:37 +02:00
global diffids treediffs
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
global parents curview
First cut at displaying the diffs for a merge. We display the files where the child differs from the first parent first in black in the file list window, followed by the second parent in blue, and so on using different colors for each parent (provided you don't have more than 6 parents; if you do we cycle around).
2005-07-17 09:39:44 +02:00
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
set diffmergeid $id
gitk: Fix two bugs reported by users The first was a simple typo where I put $yc instead of [yc $row]. The second was that I broke the logic for keeping up with fast movement through the commits, e.g. when you select a commit and then press down-arrow and let it autorepeat. That got broken when I changed the merge diff display to use git-diff-tree --cc. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-22 00:21:45 +01:00
set diffids $id
gitk: Fix file list context menu for merge commits Currently it displays an ugly error box, because the treediffs array is not filled for such commits. This fixes it by making getmergediffline add the filenames it sees to the treediffs array like gettreediffline does. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-08 09:05:37 +02:00
set treediffs($id) {}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set np [llength $parents($curview,$id)]
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
settabs $np
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
getblobdiffs $id
Improve the merge display when the result differs from all parents. Now we see if the result is quite similar to one of the parents, and if it is, display the result as a diff from that parent. If the result is similar to more than one parent, pick the one that it's most similar to.
2005-07-29 16:23:03 +02:00
}
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
proc startdiff {ids} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
global treediffs diffids treepending diffmergeid nullid nullid2
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
settabs 1
Fix display of mode changes in details pane. Also simplified the parsing of the git-diff-tree -p output and got rid of the unused 'seenfile' variable.
2005-07-17 17:11:44 +02:00
set diffids $ids
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
catch {unset diffmergeid}
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
if {![info exists treediffs($ids)] ||
[lsearch -exact $ids $nullid] >= 0 ||
[lsearch -exact $ids $nullid2] >= 0} {
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
if {![info exists treepending]} {
Make searching in files changed faster, and fix some bugs. We now kick off a single git-diff-tree -r --stdin and feed it all the commit pairs we want to know about, instead of doing a separate git-diff-tree invocation for each.
2005-07-17 03:53:55 +02:00
gettreediffs $ids
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
} else {
Make searching in files changed faster, and fix some bugs. We now kick off a single git-diff-tree -r --stdin and feed it all the commit pairs we want to know about, instead of doing a separate git-diff-tree invocation for each.
2005-07-17 03:53:55 +02:00
addtocflist $ids
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
}
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
proc path_filter {filter name} {
foreach p $filter {
set l [string length $p]
gitk: Fix a couple more bugs in the path limiting First, paths ending in a slash were not matching anything. This fixes path_filter to handle paths ending in a slash (such entries have to match a directory, and can't match a file, e.g., foo/bar/ can't match a plain file called foo/bar). Secondly, clicking in the file list pane (bottom right) was broken because $treediffs($ids) contained all the files modified by the commit, not just those within the file list. This fixes that too. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-24 02:16:56 +02:00
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
}
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
}
}
return 0
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
proc addtocflist {ids} {
gitk: Fix a couple more bugs in the path limiting First, paths ending in a slash were not matching anything. This fixes path_filter to handle paths ending in a slash (such entries have to match a directory, and can't match a file, e.g., foo/bar/ can't match a plain file called foo/bar). Secondly, clicking in the file list pane (bottom right) was broken because $treediffs($ids) contained all the files modified by the commit, not just those within the file list. This fixes that too. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-24 02:16:56 +02:00
global treediffs
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
gitk: Fix a couple more bugs in the path limiting First, paths ending in a slash were not matching anything. This fixes path_filter to handle paths ending in a slash (such entries have to match a directory, and can't match a file, e.g., foo/bar/ can't match a plain file called foo/bar). Secondly, clicking in the file list pane (bottom right) was broken because $treediffs($ids) contained all the files modified by the commit, not just those within the file list. This fixes that too. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-24 02:16:56 +02:00
add_flist $treediffs($ids)
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
getblobdiffs $ids
Make getting file lists asynchronous Add some scrollbars
2005-05-11 02:45:38 +02:00
}
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
proc diffcmd {ids flags} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
global nullid nullid2
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set i [lsearch -exact $ids $nullid]
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set j [lsearch -exact $ids $nullid2]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
if {$i >= 0} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
if {[llength $ids] > 1 && $j < 0} {
# comparing working directory with some specific revision
set cmd [concat | git diff-index $flags]
if {$i == 0} {
lappend cmd -R [lindex $ids 1]
} else {
lappend cmd [lindex $ids 0]
}
} else {
# comparing working directory with index
set cmd [concat | git diff-files $flags]
if {$j == 1} {
lappend cmd -R
}
}
} elseif {$j >= 0} {
set cmd [concat | git diff-index --cached $flags]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
if {[llength $ids] > 1} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
# comparing index with specific revision
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
if {$i == 0} {
lappend cmd -R [lindex $ids 1]
} else {
lappend cmd [lindex $ids 0]
}
} else {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
# comparing index with HEAD
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
lappend cmd HEAD
}
} else {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set cmd [concat | git diff-tree -r $flags $ids]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
return $cmd
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
proc gettreediffs {ids} {
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
global treediff treepending
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
gitk: Fixed broken exception handling in diff If the tree diff command failed to start for some random reason, treepending remained set, and thus no more diffs were shown after that. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 16:48:41 +02:00
if {[catch {set gdtf [open [diffcmd $ids {--no-commit-id}] r]}]} return
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
set treepending $ids
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
set treediff {}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
fconfigure $gdtf -blocking 0 -encoding binary
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
filerun $gdtf [list gettreediffline $gdtf $ids]
Make getting file lists asynchronous Add some scrollbars
2005-05-11 02:45:38 +02:00
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
proc gettreediffline {gdtf ids} {
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
global treediff treediffs treepending diffids diffmergeid
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
global cmitmode vfilelimit curview limitdiffs perfile_attrs
Calculate the list of interesting files for a merge. If there is a GCA for the parents of the merge, then a file is interesting if some parent has a version that is different from both the child and the GCA. If there is no GCA (e.g. for a merge that pulls in an external project) then a file is interesting if the child's version is different from all of the parents. Next step is to actually show the differences for the interesting files...
2005-07-20 15:13:46 +02:00
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set nr 0
gitk: Implement batch lookup and caching of encoding attrs When the diff contains thousands of files, calling git-check-attr once per file is very slow. With this patch gitk does attribute lookup in batches of 30 files while reading the diff file list, which leads to a very noticeable speedup. It may be possible to reimplement this even more efficiently, if git-check-attr is modified to support a --stdin-paths option. Additionally, it should quote the ':' character in file paths, or provide a more robust way of column separation. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:33 +02:00
set sublist {}
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
set max 1000
if {$perfile_attrs} {
# cache_gitattr is slow, and even slower on win32 where we
# have to invoke it for only about 30 paths at a time
set max 500
if {[tk windowingsystem] == "win32"} {
set max 120
}
}
while {[incr nr] <= $max && [gets $gdtf line] >= 0} {
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
set i [string first "\t" $line]
if {$i >= 0} {
set file [string range $line [expr {$i+1}] end]
if {[string index $file 0] eq "\""} {
set file [lindex $file 0]
}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
set file [encoding convertfrom $file]
gitk: Cope with unmerged files in local changes This modifies gettreediffline so that it when we get both a "U" line and an "M" line for the same file in the output from git diff-files or git diff-index --cached (used when the user clicks on a fake commit) we don't add the same filename to the treediff list twice. This also makes getblobdiffline recognize the "* Unmerged path ..." lines we get when we ask for the actual diffs, and makes a tiny optimization in makediffhdr. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 11:09:00 +01:00
if {$file ne [lindex $treediff end]} {
lappend treediff $file
lappend sublist $file
}
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
}
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
if {$perfile_attrs} {
cache_gitattr encoding $sublist
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
if {![eof $gdtf]} {
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
return [expr {$nr >= $max? 2: 1}]
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
}
close $gdtf
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
if {$limitdiffs && $vfilelimit($curview) ne {}} {
gitk: Fix a couple more bugs in the path limiting First, paths ending in a slash were not matching anything. This fixes path_filter to handle paths ending in a slash (such entries have to match a directory, and can't match a file, e.g., foo/bar/ can't match a plain file called foo/bar). Secondly, clicking in the file list pane (bottom right) was broken because $treediffs($ids) contained all the files modified by the commit, not just those within the file list. This fixes that too. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-24 02:16:56 +02:00
set flist {}
foreach f $treediff {
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
if {[path_filter $vfilelimit($curview) $f]} {
gitk: Fix a couple more bugs in the path limiting First, paths ending in a slash were not matching anything. This fixes path_filter to handle paths ending in a slash (such entries have to match a directory, and can't match a file, e.g., foo/bar/ can't match a plain file called foo/bar). Secondly, clicking in the file list pane (bottom right) was broken because $treediffs($ids) contained all the files modified by the commit, not just those within the file list. This fixes that too. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-24 02:16:56 +02:00
lappend flist $f
}
}
set treediffs($ids) $flist
} else {
set treediffs($ids) $treediff
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
unset treepending
gitk: Fix context menu items for generating diffs when in tree mode Currently, if you invoke the "diff this -> selected" or "diff selected -> this" and gitk is in "Tree" mode rather than "Patch" mode, the diff display pane will just show the header but not the actual diff, unless gitk has done the diff before and thus has the list of files that differ. This was because the logic in gettreediffline that checked whether we had moved on to doing something else checked the mode (Tree or Patch) before checking whether the ids we're diffing had changed. This fixes it. The new logic in gettreediffline is slightly hacky and relies on the fact that the Tree/Patch mode only applies when we're looking at a single commit, not at the diff between two commits. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 11:40:32 +01:00
if {$cmitmode eq "tree" && [llength $diffids] == 1} {
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
gettree $diffids
} elseif {$ids != $diffids} {
if {![info exists diffmergeid]} {
gettreediffs $diffids
Add "Files" and "Pickaxe" to the find menu. "Files" matches the find string against each of the files modified by each commit, and can do exact, case-ignoring or regexp matching. "Pickaxe" uses git-diff-tree -S'string' and can only do exact matching. I called it "pickaxe" rather than "find within patch" since it only finds commits where the string is present in the child but not the parents or vice versa, and "pickaxe" is what the author of that feature calls it.
2005-07-16 13:46:13 +02:00
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
} else {
addtocflist $ids
Make getting file lists asynchronous Add some scrollbars
2005-05-11 02:45:38 +02:00
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
Make getting file lists asynchronous Add some scrollbars
2005-05-11 02:45:38 +02:00
}
[PATCH] gitk: Let user easily specify lines of context in diff view More lines of context sometimes help to better understand a diff. This patch introduces a text field above the box displaying the blobdiffs. You can type in the number of lines of context that you wish to view. The number of lines of context is saved to ~/.gitk. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 12:05:46 +02:00
# empty string or positive integer
proc diffcontextvalidate {v} {
return [regexp {^(|[1-9][0-9]*)$} $v]
}
proc diffcontextchange {n1 n2 op} {
global diffcontextstring diffcontext
if {[string is integer -strict $diffcontextstring]} {
gitk: Allow diff view without context lines Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-05-23 19:31:37 +02:00
if {$diffcontextstring >= 0} {
[PATCH] gitk: Let user easily specify lines of context in diff view More lines of context sometimes help to better understand a diff. This patch introduces a text field above the box displaying the blobdiffs. You can type in the number of lines of context that you wish to view. The number of lines of context is saved to ~/.gitk. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 12:05:46 +02:00
set diffcontext $diffcontextstring
reselectline
}
}
}
[PATCH] gitk: Add checkbutton to ignore space changes Ignoring space changes can be helpful. For example, a commit claims to only reformat source code and you quickly want to verify if this claim is true. Or a commit accidentally changes code formatting and you want to focus on the real changes. In such cases a button to toggle of whitespace changes would be quite handy. You could quickly toggle between seeing and ignoring whitespace changes. This commit adds such a checkbutton right above the diff view. However, in general it is a good thing to see whitespace changes and therefore the state of the checkbutton is not saved. For example, space changes might happen unintentionally. But they are real changes yielding different sha1s for the blobs involved. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-17 23:42:55 +01:00
proc changeignorespace {} {
reselectline
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
proc getblobdiffs {ids} {
gitk: Get rid of the diffopts variable The only thing that could be specified with diffopts was the number of lines of context, but there is already a spinbox for that. So this gets rid of it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:22:00 +02:00
global blobdifffd diffids env
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
global diffinhdr treediffs
[PATCH] gitk: Let user easily specify lines of context in diff view More lines of context sometimes help to better understand a diff. This patch introduces a text field above the box displaying the blobdiffs. You can type in the number of lines of context that you wish to view. The number of lines of context is saved to ~/.gitk. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 12:05:46 +02:00
global diffcontext
[PATCH] gitk: Add checkbutton to ignore space changes Ignoring space changes can be helpful. For example, a commit claims to only reformat source code and you quickly want to verify if this claim is true. Or a commit accidentally changes code formatting and you want to focus on the real changes. In such cases a button to toggle of whitespace changes would be quite handy. You could quickly toggle between seeing and ignoring whitespace changes. This commit adds such a checkbutton right above the diff view. However, in general it is a good thing to see whitespace changes and therefore the state of the checkbutton is not saved. For example, space changes might happen unintentionally. But they are real changes yielding different sha1s for the blobs involved. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-17 23:42:55 +01:00
global ignorespace
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
global limitdiffs vfilelimit curview
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
global diffencoding targetline diffnparents
gitk: Check git version before using --textconv flag Commit 785b7535 ("gitk: use --textconv to generate diff text") added the --textconv flag to the git diff commands used to display commit diffs. Since some people use newer gitk with older git installations, this adds a check on the git version to check that it understands --textconv before using it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-05-16 13:06:01 +02:00
global git_version
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
gitk: Check git version before using --textconv flag Commit 785b7535 ("gitk: use --textconv to generate diff text") added the --textconv flag to the git diff commands used to display commit diffs. Since some people use newer gitk with older git installations, this adds a check on the git version to check that it understands --textconv before using it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-05-16 13:06:01 +02:00
set textconv {}
if {[package vcompare $git_version "1.6.1"] >= 0} {
set textconv "--textconv"
}
set cmd [diffcmd $ids "-p $textconv -C --cc --no-commit-id -U$diffcontext"]
[PATCH] gitk: Add checkbutton to ignore space changes Ignoring space changes can be helpful. For example, a commit claims to only reformat source code and you quickly want to verify if this claim is true. Or a commit accidentally changes code formatting and you want to focus on the real changes. In such cases a button to toggle of whitespace changes would be quite handy. You could quickly toggle between seeing and ignoring whitespace changes. This commit adds such a checkbutton right above the diff view. However, in general it is a good thing to see whitespace changes and therefore the state of the checkbutton is not saved. For example, space changes might happen unintentionally. But they are real changes yielding different sha1s for the blobs involved. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-17 23:42:55 +01:00
if {$ignorespace} {
append cmd " -w"
}
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
if {$limitdiffs && $vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
}
if {[catch {set bdf [open $cmd r]} err]} {
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
error_popup [mc "Error getting diffs: %s" $err]
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
return
}
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
set targetline {}
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
set diffnparents 0
Fix display of mode changes in details pane. Also simplified the parsing of the git-diff-tree -p output and got rid of the unused 'seenfile' variable.
2005-07-17 17:11:44 +02:00
set diffinhdr 0
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
set diffencoding [get_path_encoding {}]
gitk: Handle blobs containing a DOS end-of-file marker If a patchset contains an EOF marker (Ctrl-Z) the blob diff terminates at that point. This permits gitk to ignore the eof and continue to display any subsequent blobs and also displays a sensible representation of the eof char. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-16 11:24:40 +01:00
fconfigure $bdf -blocking 0 -encoding binary -eofchar {}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
set blobdifffd($ids) $bdf
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
filerun $bdf [list getblobdiffline $bdf $diffids]
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
}
gitk: Fix file list display when files are renamed The conversion of the file list to use a text widget assumed incorrectly that the list of files from git-diff-tree -r would correspond 1-1 with the diff sections in the output of git-diff-tree -r -p -C, which is not true when renames are detected. This fixes it by keeping the elements in the difffilestart list in the order they appear in the file list window. Since this means that the elements of difffilestart are no longer necessarily in ascending order, it's somewhat hard to do the dynamic highlighting in the file list as the diff window is scrolled, so I have taken that out for now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 11:55:31 +02:00
proc setinlist {var i val} {
global $var
while {[llength [set $var]] < $i} {
lappend $var {}
}
if {[llength [set $var]] == $i} {
lappend $var $val
} else {
lset $var $i $val
}
}
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
proc makediffhdr {fname ids} {
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
global ctext curdiffstart treediffs diffencoding
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
global ctext_file_names jump_to_here targetline diffline
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
set fname [encoding convertfrom $fname]
set diffencoding [get_path_encoding $fname]
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
}
gitk: Cope with unmerged files in local changes This modifies gettreediffline so that it when we get both a "U" line and an "M" line for the same file in the output from git diff-files or git diff-index --cached (used when the user clicks on a fake commit) we don't add the same filename to the treediff list twice. This also makes getblobdiffline recognize the "* Unmerged path ..." lines we get when we ask for the actual diffs, and makes a tiny optimization in makediffhdr. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 11:09:00 +01:00
lset ctext_file_names end $fname
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
set l [expr {(78 - [string length $fname]) / 2}]
set pad [string range "----------------------------------------" 1 $l]
$ctext insert $curdiffstart "$pad $fname $pad" filesep
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
set targetline {}
if {$jump_to_here ne {} && [lindex $jump_to_here 0] eq $fname} {
set targetline [lindex $jump_to_here 1]
}
set diffline 0
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
proc getblobdiffline {bdf ids} {
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
global diffids blobdifffd ctext curdiffstart
Handle the rename cases reported by git-diff-tree -C correctly.
2005-07-20 18:25:54 +02:00
global diffnexthead diffnextnote difffilestart
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
global ctext_file_names ctext_file_lines
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
global diffinhdr treediffs mergemax diffnparents
gitk: Add a menu item to show where a given line comes from This adds a menu item to the pop-up menu for the diff display window which makes gitk find which commit added the line (via git blame) and show that commit, with the line highlighted with a light-blue background. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 11:36:25 +01:00
global diffencoding jump_to_here targetline diffline
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set nr 0
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
$ctext conf -state normal
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
while {[incr nr] <= 1000 && [gets $bdf line] >= 0} {
if {$ids != $diffids || $bdf != $blobdifffd($ids)} {
gitk: Show diff of commits at end of compare-commits output When comparing a string of commits, when we find two non-merge commits that differ, we now write the two commits to files and diff the files. This pulls out the logic for creating a temporary directory from external_diff into a separate procedure so that the new diffcommits procedure can use it. Because the diff command returns an exit status of 1 when the files differ, and Tcl treats that as an error, this adds catch {} around the close statements in getblobdiffline. At present this only removes the temporary files when gitk exits. It should remove them when the diff is done. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-07 02:08:21 +02:00
catch {close $bdf}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
gitk: Fix file list display when files are renamed The conversion of the file list to use a text widget assumed incorrectly that the list of files from git-diff-tree -r would correspond 1-1 with the diff sections in the output of git-diff-tree -r -p -C, which is not true when renames are detected. This fixes it by keeping the elements in the difffilestart list in the order they appear in the file list window. Since this means that the elements of difffilestart are no longer necessarily in ascending order, it's somewhat hard to do the dynamic highlighting in the file list as the diff window is scrolled, so I have taken that out for now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 11:55:31 +02:00
}
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
if {![string compare -length 5 "diff " $line]} {
if {![regexp {^diff (--cc|--git) } $line m type]} {
set line [encoding convertfrom $line]
$ctext insert end "$line\n" hunksep
continue
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
# start of a new file
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
set diffinhdr 1
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
$ctext insert end "\n"
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
set curdiffstart [$ctext index "end - 1c"]
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
lappend ctext_file_names ""
lappend ctext_file_lines [lindex [split $curdiffstart "."] 0]
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
$ctext insert end "\n" filesep
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
if {$type eq "--cc"} {
# start of a new file in a merge diff
set fname [string range $line 10 end]
if {[lsearch -exact $treediffs($ids) $fname] < 0} {
lappend treediffs($ids) $fname
add_flist [list $fname]
}
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
} else {
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
set line [string range $line 11 end]
# If the name hasn't changed the length will be odd,
# the middle char will be a space, and the two bits either
# side will be a/name and b/name, or "a/name" and "b/name".
# If the name has changed we'll get "rename from" and
# "rename to" or "copy from" and "copy to" lines following
# this, and we'll use them to get the filenames.
# This complexity is necessary because spaces in the
# filename(s) don't get escaped.
set l [string length $line]
set i [expr {$l / 2}]
if {!(($l & 1) && [string index $line $i] eq " " &&
[string range $line 2 [expr {$i - 1}]] eq \
[string range $line [expr {$i + 3}] end])} {
continue
}
# unescape if quoted and chop off the a/ from the front
if {[string index $line 0] eq "\""} {
set fname [string range [lindex $line 0] 2 end]
} else {
set fname [string range $line 2 [expr {$i - 1}]]
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
}
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
makediffhdr $fname $ids
gitk: Cope with unmerged files in local changes This modifies gettreediffline so that it when we get both a "U" line and an "M" line for the same file in the output from git diff-files or git diff-index --cached (used when the user clicks on a fake commit) we don't add the same filename to the treediff list twice. This also makes getblobdiffline recognize the "* Unmerged path ..." lines we get when we ask for the actual diffs, and makes a tiny optimization in makediffhdr. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-04 11:09:00 +01:00
} elseif {![string compare -length 16 "* Unmerged path " $line]} {
set fname [encoding convertfrom [string range $line 16 end]]
$ctext insert end "\n"
set curdiffstart [$ctext index "end - 1c"]
lappend ctext_file_names $fname
lappend ctext_file_lines [lindex [split $curdiffstart "."] 0]
$ctext insert end "$line\n" filesep
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
}
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
} elseif {![string compare -length 2 "@@" $line]} {
regexp {^@@+} $line ats
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
set line [encoding convertfrom $diffencoding $line]
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
$ctext insert end "$line\n" hunksep
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
if {[regexp { \+(\d+),\d+ @@} $line m nl]} {
set diffline $nl
}
set diffnparents [expr {[string length $ats] - 1}]
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set diffinhdr 0
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
} elseif {$diffinhdr} {
gitk: Do not pick up file names of "copy from" lines 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> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-02 16:16:54 +02:00
if {![string compare -length 12 "rename from " $line]} {
[PATCH] gitk: Handle 'copy from' and 'copy to' in diff headers. If a commit contained a copy operation, the file name was not correctly determined, and the corresponding part of the patch could not be navigated to from the list of files. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-16 14:32:29 +02:00
set fname [string range $line [expr 6 + [string first " from " $line] ] end]
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
set fname [encoding convertfrom $fname]
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
}
[PATCH] gitk: Handle 'copy from' and 'copy to' in diff headers. If a commit contained a copy operation, the file name was not correctly determined, and the corresponding part of the patch could not be navigated to from the list of files. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-16 14:32:29 +02:00
} elseif {![string compare -length 10 $line "rename to "] ||
![string compare -length 8 $line "copy to "]} {
set fname [string range $line [expr 4 + [string first " to " $line] ] end]
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
makediffhdr $fname $ids
} elseif {[string compare -length 3 $line "---"] == 0} {
# do nothing
continue
} elseif {[string compare -length 3 $line "+++"] == 0} {
set diffinhdr 0
continue
}
$ctext insert end "$line\n" filesep
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
} else {
gitk: Handle blobs containing a DOS end-of-file marker If a patchset contains an EOF marker (Ctrl-Z) the blob diff terminates at that point. This permits gitk to ignore the eof and continue to display any subsequent blobs and also displays a sensible representation of the eof char. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-16 11:24:40 +01:00
set line [string map {\x1A ^Z} \
[encoding convertfrom $diffencoding $line]]
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
# parse the prefix - one ' ', '-' or '+' for each parent
set prefix [string range $line 0 [expr {$diffnparents - 1}]]
set tag [expr {$diffnparents > 1? "m": "d"}]
if {[string trim $prefix " -+"] eq {}} {
# prefix only has " ", "-" and "+" in it: normal diff line
set num [string first "-" $prefix]
if {$num >= 0} {
# removed line, first parent with line is $num
if {$num >= $mergemax} {
set num "max"
}
$ctext insert end "$line\n" $tag$num
} else {
set tags {}
if {[string first "+" $prefix] >= 0} {
# added line
lappend tags ${tag}result
if {$diffnparents > 1} {
set num [string first " " $prefix]
if {$num >= 0} {
if {$num >= $mergemax} {
set num "max"
}
lappend tags m$num
}
}
}
if {$targetline ne {}} {
if {$diffline == $targetline} {
set seehere [$ctext index "end - 1 chars"]
set targetline {}
} else {
incr diffline
}
}
$ctext insert end "$line\n" $tags
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
} else {
gitk: Improve handling of whitespace and special chars in filenames The main thing here is better parsing of the diff --git lines in the output of git diff-tree -p. We now cope with filenames in quotes with special chars escaped. If the filenames contain spaces they aren't quoted, however, which can create difficulties in parsing. We get around the difficulties by detecting the case when the filename hasn't changed (chop the part after "diff --git " in two and see if the halves match apart from a/ in one and b/ in the other), and if it hasn't changed, we just use one half. If the filename has changed we wait for the "rename from" and "rename to" lines, which give the old and new filenames unambiguously. This also improves the parsing of the output of git diff-tree. Instead of using lindex to extract the filename, we take the part from the first tab on, and if it starts with a quote, we use [lindex $str 0] to remove the quotes and convert the escapes. This also gets rid of some unused tagging of the diff text, uses [string compare] instead of [regexp] in some places, and fixes the regexp for detecting the @@ hunk-separator lines (the regexp wasn't accepting a single number, as in "-0,0 +1" for example). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-23 12:28:15 +02:00
# "\ No newline at end of file",
# or something else we don't recognize
$ctext insert end "$line\n" hunksep
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
}
}
}
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
if {[info exists seehere]} {
mark_ctext_line [lindex [split $seehere .] 0]
}
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
$ctext conf -state disabled
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
if {[eof $bdf]} {
gitk: Show diff of commits at end of compare-commits output When comparing a string of commits, when we find two non-merge commits that differ, we now write the two commits to files and diff the files. This pulls out the logic for creating a temporary directory from external_diff into a separate procedure so that the new diffcommits procedure can use it. Because the diff command returns an exit status of 1 when the files differ, and Tcl treats that as an error, this adds catch {} around the close statements in getblobdiffline. At present this only removes the temporary files when gitk exits. It should remove them when the diff is done. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-07 02:08:21 +02:00
catch {close $bdf}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return [expr {$nr >= 1000? 2: 1}]
Show the diffs when a commit is selected Selecting in the listbox reduces the text view to just the diff for the file(s) selected Added -c option for color-by-committer Added some more key bindings
2005-05-12 01:44:54 +02:00
}
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
proc changediffdisp {} {
global ctext diffelide
$ctext tag conf d0 -elide [lindex $diffelide 0]
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
$ctext tag conf dresult -elide [lindex $diffelide 1]
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
}
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
proc highlightfile {loc cline} {
global ctext cflist cflist_top
$ctext yview $loc
$cflist tag remove highlight $cflist_top.0 "$cflist_top.0 lineend"
$cflist tag add highlight $cline.0 "$cline.0 lineend"
$cflist see $cline.0
set cflist_top $cline
}
[PATCH] gitk: Fix nextfile() and add prevfile() The current nextfile() jumps to last hunk, but I think this is not intention, probably, it's forgetting to add "break;". And this patch also adds prevfile(), it jumps to previous hunk. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 05:32:19 +02:00
proc prevfile {} {
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
global difffilestart ctext cmitmode
if {$cmitmode eq "tree"} return
set prev 0.0
set prevline 1
[PATCH] gitk: Fix nextfile() and add prevfile() The current nextfile() jumps to last hunk, but I think this is not intention, probably, it's forgetting to add "break;". And this patch also adds prevfile(), it jumps to previous hunk. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 05:32:19 +02:00
set here [$ctext index @0,0]
foreach loc $difffilestart {
if {[$ctext compare $loc >= $here]} {
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
highlightfile $prev $prevline
[PATCH] gitk: Fix nextfile() and add prevfile() The current nextfile() jumps to last hunk, but I think this is not intention, probably, it's forgetting to add "break;". And this patch also adds prevfile(), it jumps to previous hunk. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 05:32:19 +02:00
return
}
set prev $loc
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
incr prevline
[PATCH] gitk: Fix nextfile() and add prevfile() The current nextfile() jumps to last hunk, but I think this is not intention, probably, it's forgetting to add "break;". And this patch also adds prevfile(), it jumps to previous hunk. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 05:32:19 +02:00
}
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
highlightfile $prev $prevline
[PATCH] gitk: Fix nextfile() and add prevfile() The current nextfile() jumps to last hunk, but I think this is not intention, probably, it's forgetting to add "break;". And this patch also adds prevfile(), it jumps to previous hunk. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 05:32:19 +02:00
}
Accommodate new git-diff-tree output format Add 'f' key for moving to next file
2005-05-19 14:35:53 +02:00
proc nextfile {} {
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
global difffilestart ctext cmitmode
if {$cmitmode eq "tree"} return
Accommodate new git-diff-tree output format Add 'f' key for moving to next file
2005-05-19 14:35:53 +02:00
set here [$ctext index @0,0]
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
set line 1
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
foreach loc $difffilestart {
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
incr line
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
if {[$ctext compare $loc > $here]} {
gitk: Synchronize highlighting in file view for 'f' and 'b' commands This is based on a patch by Eric Raible <raible@gmail.com>, but does things a bit more simply. Previously, 'b', backspace, and delete all did the same thing. This changes 'b' to perform the inverse of 'f'. And both of them now highlight the filename of the currently diff. This makes it easier to review and navigate the diffs associated with a particular commit using only f, b, and space because the filename of the currently display diff will be dynamically highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-10 05:15:36 +02:00
highlightfile $loc $line
[PATCH] gitk: Fix nextfile() and add prevfile() The current nextfile() jumps to last hunk, but I think this is not intention, probably, it's forgetting to add "break;". And this patch also adds prevfile(), it jumps to previous hunk. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-27 05:32:19 +02:00
return
Accommodate new git-diff-tree output format Add 'f' key for moving to next file
2005-05-19 14:35:53 +02:00
}
}
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
}
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
proc clear_ctext {{first 1.0}} {
global ctext smarktop smarkbot
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
global ctext_file_names ctext_file_lines
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
global pendinglinks
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
set l [lindex [split $first .] 0]
if {![info exists smarktop] || [$ctext compare $first < $smarktop.0]} {
set smarktop $l
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
}
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
if {![info exists smarkbot] || [$ctext compare $first < $smarkbot.0]} {
set smarkbot $l
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
}
$ctext delete $first end
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
if {$first eq "1.0"} {
catch {unset pendinglinks}
}
gitk: Allow starting gui blame for a specific line This adds a context menu item to the diff viewer pane that calls git gui blame, focusing it on the clicked line. In case of combined diffs, it also automatically deduces which parent is to be blamed. Lines added by the diff are blamed on the current commit itself. The context menu itself is added by this patch. It would be possible to add the commands from the flist menu to it. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-24 10:13:01 +02:00
set ctext_file_names {}
set ctext_file_lines {}
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
}
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
proc settabs {{firstab {}}} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
global firsttabstop tabstop ctext have_tk85
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
if {$firstab ne {} && $have_tk85} {
set firsttabstop $firstab
}
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set w [font measure textfont "0"]
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
if {$firsttabstop != 0} {
gitk: Fix bug causing Tcl error when changing find match type When changing the selector for Exact/IgnCase/Regexp, we were getting a Tcl error. This fixes it. It also adds a workaround for a bug in alpha versions of Tk8.5 where wordprocessor-style tabs don't seem to work properly around column 1. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:19:24 +02:00
$ctext conf -tabs [list [expr {($firsttabstop + $tabstop) * $w}] \
[expr {($firsttabstop + 2 * $tabstop) * $w}]]
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
} elseif {$have_tk85 || $tabstop != 8} {
$ctext conf -tabs [expr {$tabstop * $w}]
} else {
$ctext conf -tabs {}
}
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
}
proc incrsearch {name ix op} {
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
global ctext searchstring searchdirn
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
$ctext tag remove found 1.0 end
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
if {[catch {$ctext index anchor}]} {
# no anchor set, use start of selection, or of visible area
set sel [$ctext tag ranges sel]
if {$sel ne {}} {
$ctext mark set anchor [lindex $sel 0]
} elseif {$searchdirn eq "-forwards"} {
$ctext mark set anchor @0,0
} else {
$ctext mark set anchor @0,[winfo height $ctext]
}
}
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
if {$searchstring ne {}} {
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
set here [$ctext search $searchdirn -- $searchstring anchor]
if {$here ne {}} {
$ctext see $here
}
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
searchmarkvisible 1
}
}
proc dosearch {} {
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
global sstring ctext searchstring searchdirn
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
focus $sstring
$sstring icursor end
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
set searchdirn -forwards
if {$searchstring ne {}} {
set sel [$ctext tag ranges sel]
if {$sel ne {}} {
set start "[lindex $sel 0] + 1c"
} elseif {[catch {set start [$ctext index anchor]}]} {
set start "@0,0"
}
set match [$ctext search -count mlen -- $searchstring $start]
$ctext tag remove sel 1.0 end
if {$match eq {}} {
bell
return
}
$ctext see $match
set mend "$match + $mlen c"
$ctext tag add sel $match $mend
$ctext mark unset anchor
}
}
proc dosearchback {} {
global sstring ctext searchstring searchdirn
focus $sstring
$sstring icursor end
set searchdirn -backwards
if {$searchstring ne {}} {
set sel [$ctext tag ranges sel]
if {$sel ne {}} {
set start [lindex $sel 0]
} elseif {[catch {set start [$ctext index anchor]}]} {
set start @0,[winfo height $ctext]
}
set match [$ctext search -backwards -count ml -- $searchstring $start]
$ctext tag remove sel 1.0 end
if {$match eq {}} {
bell
return
}
$ctext see $match
set mend "$match + $ml c"
$ctext tag add sel $match $mend
$ctext mark unset anchor
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
}
}
proc searchmark {first last} {
global ctext searchstring
set mend $first.0
while {1} {
set match [$ctext search -count mlen -- $searchstring $mend $last.end]
if {$match eq {}} break
set mend "$match + $mlen c"
$ctext tag add found $match $mend
}
}
proc searchmarkvisible {doall} {
global ctext smarktop smarkbot
set topline [lindex [split [$ctext index @0,0] .] 0]
set botline [lindex [split [$ctext index @0,[winfo height $ctext]] .] 0]
if {$doall || $botline < $smarktop || $topline > $smarkbot} {
# no overlap with previous
searchmark $topline $botline
set smarktop $topline
set smarkbot $botline
} else {
if {$topline < $smarktop} {
searchmark $topline [expr {$smarktop-1}]
set smarktop $topline
}
if {$botline > $smarkbot} {
searchmark [expr {$smarkbot+1}] $botline
set smarkbot $botline
}
}
}
proc scrolltext {f0 f1} {
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
global searchstring
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
[PATCH] gitk: Add horizontal scrollbar to the diff view Adding horizontal scroll bar makes the scrolling feature more discoverable to the users. The horizontal scrollbar is a bit narrower than vertical ones so we don't make too big impact on available screen real estate. The text and scrollbar widget layout is done using grid geometry manager. An interesting side effect of Tk scrollbars is that the "elevator" size changes depending on the visible content. So the horizontal scrollbar "elevator" changes as the user scrolls the view up and down. Signed-off-by: Pekka Kaitaniemi <kaitanie@cc.helsinki.fi> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-08 13:27:23 +01:00
.bleft.bottom.sb set $f0 $f1
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
if {$searchstring ne {}} {
searchmarkvisible 0
}
}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
proc setcoords {} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
global linespc charspc canvx0 canvy0
Allow graph lines to jump through hyperspace. When the graph gets too wide (as defined by the maxwidth variable, which can be set in ~/.gitk), we can now terminate graph lines with an arrow pointing downwards, and reintroduce them later with an arrow pointing upwards when we need them. This makes the graph much less cluttered on large repositories such as the linux kernel. Unfortunately this has made it slower; it takes about 10 seconds user time on the linux-2.6 repository on my machine now, compared to 6 seconds before. I'll have to work on optimizing that. Also on the todo list are making the arrow heads active (so if you click on them you jump to the other end) and improving the placement of the null entry.
2005-08-18 01:30:10 +02:00
global xspc1 xspc2 lthickness
Compress the graph horizontally if it gets too wide. If the graph gets to use more than a certain percentage (default 50%) of the width of the top-left pane, we now reduce the amount of space allowed for each graph line. This means it doesn't look quite as nice but you can still see the headline for the commit. (Currently the only way to customize the percentage is to edit your ~/.gitk file manually.)
2005-08-05 01:52:16 +02:00
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set linespc [font metrics mainfont -linespace]
set charspc [font measure mainfont "m"]
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
set canvy0 [expr {int(3 + 0.5 * $linespc)}]
set canvx0 [expr {int(3 + 0.5 * $linespc)}]
Allow graph lines to jump through hyperspace. When the graph gets too wide (as defined by the maxwidth variable, which can be set in ~/.gitk), we can now terminate graph lines with an arrow pointing downwards, and reintroduce them later with an arrow pointing upwards when we need them. This makes the graph much less cluttered on large repositories such as the linux kernel. Unfortunately this has made it slower; it takes about 10 seconds user time on the linux-2.6 repository on my machine now, compared to 6 seconds before. I'll have to work on optimizing that. Also on the todo list are making the arrow heads active (so if you click on them you jump to the other end) and improving the placement of the null entry.
2005-08-18 01:30:10 +02:00
set lthickness [expr {int($linespc / 9) + 1}]
Compress the graph horizontally if it gets too wide. If the graph gets to use more than a certain percentage (default 50%) of the width of the top-left pane, we now reduce the amount of space allowed for each graph line. This means it doesn't look quite as nice but you can still see the headline for the commit. (Currently the only way to customize the percentage is to edit your ~/.gitk file manually.)
2005-08-05 01:52:16 +02:00
set xspc1(0) $linespc
set xspc2 $linespc
Make behaviour when git-rev-tree fails nicer Fix crash benh saw with currentid undefined Add menu with file/quit and help/about items Add ^Q for quit
2005-05-13 01:46:16 +02:00
}
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
proc redisplay {} {
gitk: Allow top panes to scroll horizontally with mouse button 2 Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 00:55:11 +02:00
global canv
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
global selectedline
set ymax [lindex [$canv cget -scrollregion] 3]
if {$ymax eq {} || $ymax == 0} return
set span [$canv yview]
clear_display
gitk: Allow top panes to scroll horizontally with mouse button 2 Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-31 00:55:11 +02:00
setcanvscroll
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
allcanvs yview moveto [lindex $span 0]
drawvisible
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline ne {}} {
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
selectline $selectedline 0
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
allcanvs yview moveto [lindex $span 0]
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
}
}
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
proc parsefont {f n} {
global fontattr
set fontattr($f,family) [lindex $n 0]
set s [lindex $n 1]
if {$s eq {} || $s == 0} {
set s 10
} elseif {$s < 0} {
set s [expr {int(-$s / [winfo fpixels . 1p] + 0.5)}]
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
}
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
set fontattr($f,size) $s
set fontattr($f,weight) normal
set fontattr($f,slant) roman
foreach style [lrange $n 2 end] {
switch -- $style {
"normal" -
"bold" {set fontattr($f,weight) $style}
"roman" -
"italic" {set fontattr($f,slant) $style}
}
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
}
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
}
proc fontflags {f {isbold 0}} {
global fontattr
return [list -family $fontattr($f,family) -size $fontattr($f,size) \
-weight [expr {$isbold? "bold": $fontattr($f,weight)}] \
-slant $fontattr($f,slant)]
}
proc fontname {f} {
global fontattr
set n [list $fontattr($f,family) $fontattr($f,size)]
if {$fontattr($f,weight) eq "bold"} {
lappend n "bold"
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
}
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
if {$fontattr($f,slant) eq "italic"} {
lappend n "italic"
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
}
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
return $n
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
proc incrfont {inc} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global mainfont textfont ctext canv cflist showrefstop
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
global stopped entries fontattr
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
unmarkmatches
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
set s $fontattr(mainfont,size)
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
incr s $inc
if {$s < 1} {
set s 1
}
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
set fontattr(mainfont,size) $s
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
font config mainfont -size $s
font config mainfontbold -size $s
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
set mainfont [fontname mainfont]
set s $fontattr(textfont,size)
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
incr s $inc
if {$s < 1} {
set s 1
}
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
set fontattr(textfont,size) $s
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
font config textfont -size $s
font config textfontbold -size $s
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
set textfont [fontname textfont]
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
setcoords
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
settabs
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
redisplay
}
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
Clear the SHA1 entry field when we go to paste something into it If the user pastes in the selection (with the middle mouse button) and it already has 40 characters in it, clear it before pasting.
2005-06-25 08:37:13 +02:00
proc clearsha1 {} {
global sha1entry sha1string
if {[string length $sha1string] == 40} {
$sha1entry delete 0 end
}
}
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
proc sha1change {n1 n2 op} {
global sha1string currentid sha1but
if {$sha1string == {}
|| ([info exists currentid] && $sha1string == $currentid)} {
set state disabled
} else {
set state normal
}
if {[$sha1but cget -state] == $state} return
if {$state == "normal"} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$sha1but conf -state normal -relief raised -text "[mc "Goto:"] "
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
} else {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$sha1but conf -state disabled -relief flat -text "[mc "SHA1 ID:"] "
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
}
}
proc gotocommit {} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global sha1string tagids headids curview varcid
Allow short SHA1 IDs in the SHA1 entry field.
2005-07-18 18:16:35 +02:00
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
if {$sha1string == {}
|| ([info exists currentid] && $sha1string == $currentid)} return
if {[info exists tagids($sha1string)]} {
set id $tagids($sha1string)
[PATCH] gitk: allow goto heads This patch allows you to enter a head name in the SHA1 id: field. It also removes some unnecessary global declarations. Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-30 07:13:12 +02:00
} elseif {[info exists headids($sha1string)]} {
set id $headids($sha1string)
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
} else {
set id [string tolower $sha1string]
Allow short SHA1 IDs in the SHA1 entry field.
2005-07-18 18:16:35 +02:00
if {[regexp {^[0-9a-f]{4,39}$} $id]} {
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
set matches [longid $id]
Allow short SHA1 IDs in the SHA1 entry field.
2005-07-18 18:16:35 +02:00
if {$matches ne {}} {
if {[llength $matches] > 1} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
error_popup [mc "Short SHA1 id %s is ambiguous" $id]
Allow short SHA1 IDs in the SHA1 entry field.
2005-07-18 18:16:35 +02:00
return
}
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
set id [lindex $matches 0]
Allow short SHA1 IDs in the SHA1 entry field.
2005-07-18 18:16:35 +02:00
}
gitk: Parse arbitrary commit-ish in SHA1 field We only accepted either SHA1s or heads/tags that have been read. This meant the user could not, e.g., enter HEAD to go back to the current commit. This adds code to call out to git rev-parse --verify if all other methods of interpreting the string the user entered fail. (git-rev-parse alone is not enough as we really want a single revision.) The error paths change slighly, because we now know from the rev-parse invocation whether the expression was valid at all. The previous "unknown" path is now only triggered if the revision does exist, but is not in the current view display. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-13 09:25:03 +02:00
} else {
if {[catch {set id [exec git rev-parse --verify $sha1string]}]} {
error_popup [mc "Revision %s is not known" $sha1string]
return
}
Allow short SHA1 IDs in the SHA1 entry field.
2005-07-18 18:16:35 +02:00
}
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
}
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $id $curview]} {
selectline [rowofcommit $id] 1
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
return
}
Allow short SHA1 IDs in the SHA1 entry field.
2005-07-18 18:16:35 +02:00
if {[regexp {^[0-9a-fA-F]{4,}$} $sha1string]} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
set msg [mc "SHA1 id %s is not known" $sha1string]
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
} else {
gitk: Parse arbitrary commit-ish in SHA1 field We only accepted either SHA1s or heads/tags that have been read. This meant the user could not, e.g., enter HEAD to go back to the current commit. This adds code to call out to git rev-parse --verify if all other methods of interpreting the string the user entered fail. (git-rev-parse alone is not enough as we really want a single revision.) The error paths change slighly, because we now know from the rev-parse invocation whether the expression was valid at all. The previous "unknown" path is now only triggered if the revision does exist, but is not in the current view display. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-13 09:25:03 +02:00
set msg [mc "Revision %s is not in the current view" $sha1string]
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
}
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
error_popup $msg
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
}
Draw graph lines as one continuous line where possible Added context menu on lines Added headline display when the mouse hovers over a line Removed some debug messages
2005-06-17 02:12:26 +02:00
proc lineenter {x y id} {
global hoverx hovery hoverid hovertimer
global commitinfo canv
gitk: Further speedups Now we don't parse the commits as we are reading them, we just put commit data on a list as a blob, and instead parse the commit when we need the various parts of it, such as when a commit is drawn on the canvas. This makes searching a bit more interesting: now we scan through the commit blobs doing a string or regexp match to find commits that might match, then for those that might match, we parse the commit info (if it isn't already parsed) and do the matching for the various fields as before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 12:56:44 +01:00
if {![info exists commitinfo($id)] && ![getcommit $id]} return
Draw graph lines as one continuous line where possible Added context menu on lines Added headline display when the mouse hovers over a line Removed some debug messages
2005-06-17 02:12:26 +02:00
set hoverx $x
set hovery $y
set hoverid $id
if {[info exists hovertimer]} {
after cancel $hovertimer
}
set hovertimer [after 500 linehover]
$canv delete hover
}
proc linemotion {x y id} {
global hoverx hovery hoverid hovertimer
if {[info exists hoverid] && $id == $hoverid} {
set hoverx $x
set hovery $y
if {[info exists hovertimer]} {
after cancel $hovertimer
}
set hovertimer [after 500 linehover]
}
}
proc lineleave {id} {
global hoverid hovertimer canv
if {[info exists hoverid] && $id == $hoverid} {
$canv delete hover
if {[info exists hovertimer]} {
after cancel $hovertimer
unset hovertimer
}
unset hoverid
}
}
proc linehover {} {
global hoverx hovery hoverid hovertimer
global canv linespc lthickness
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
global commitinfo
Draw graph lines as one continuous line where possible Added context menu on lines Added headline display when the mouse hovers over a line Removed some debug messages
2005-06-17 02:12:26 +02:00
set text [lindex $commitinfo($hoverid) 0]
set ymax [lindex [$canv cget -scrollregion] 3]
if {$ymax == {}} return
set yfrac [lindex [$canv yview] 0]
set x [expr {$hoverx + 2 * $linespc}]
set y [expr {$hovery + $yfrac * $ymax - $linespc / 2}]
set x0 [expr {$x - 2 * $lthickness}]
set y0 [expr {$y - 2 * $lthickness}]
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
set x1 [expr {$x + [font measure mainfont $text] + 2 * $lthickness}]
Draw graph lines as one continuous line where possible Added context menu on lines Added headline display when the mouse hovers over a line Removed some debug messages
2005-06-17 02:12:26 +02:00
set y1 [expr {$y + $linespc + 2 * $lthickness}]
set t [$canv create rectangle $x0 $y0 $x1 $y1 \
-fill \#ffff80 -outline black -width 1 -tags hover]
$canv raise $t
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
set t [$canv create text $x $y -anchor nw -text $text -tags hover \
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
-font mainfont]
Draw graph lines as one continuous line where possible Added context menu on lines Added headline display when the mouse hovers over a line Removed some debug messages
2005-06-17 02:12:26 +02:00
$canv raise $t
}
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
proc clickisonarrow {id y} {
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
global lthickness
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set ranges [rowranges $id]
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
set thresh [expr {2 * $lthickness + 6}]
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set n [expr {[llength $ranges] - 1}]
gitk: Fix clicks on arrows on line ends With the new representation of the graph lines, this turns out much simpler now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 00:02:03 +01:00
for {set i 1} {$i < $n} {incr i} {
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set row [lindex $ranges $i]
gitk: Fix clicks on arrows on line ends With the new representation of the graph lines, this turns out much simpler now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 00:02:03 +01:00
if {abs([yc $row] - $y) < $thresh} {
return $i
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
}
}
return {}
}
gitk: Fix clicks on arrows on line ends With the new representation of the graph lines, this turns out much simpler now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 00:02:03 +01:00
proc arrowjump {id n y} {
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
global canv
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
gitk: Fix clicks on arrows on line ends With the new representation of the graph lines, this turns out much simpler now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 00:02:03 +01:00
# 1 <-> 2, 3 <-> 4, etc...
set n [expr {(($n - 1) ^ 1) + 1}]
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set row [lindex [rowranges $id] $n]
gitk: Fix clicks on arrows on line ends With the new representation of the graph lines, this turns out much simpler now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 00:02:03 +01:00
set yt [yc $row]
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
set ymax [lindex [$canv cget -scrollregion] 3]
if {$ymax eq {} || $ymax <= 0} return
set view [$canv yview]
set yspan [expr {[lindex $view 1] - [lindex $view 0]}]
set yfrac [expr {$yt / $ymax - $yspan / 2}]
if {$yfrac < 0} {
set yfrac 0
}
gitk: Fix clicks on arrows on line ends With the new representation of the graph lines, this turns out much simpler now. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-28 00:02:03 +01:00
allcanvs yview moveto $yfrac
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
}
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
proc lineclick {x y id isnew} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global ctext commitinfo children canv thickerline curview
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
gitk: Further speedups Now we don't parse the commits as we are reading them, we just put commit data on a list as a blob, and instead parse the commit when we need the various parts of it, such as when a commit is drawn on the canvas. This makes searching a bit more interesting: now we scan through the commit blobs doing a string or regexp match to find commits that might match, then for those that might match, we parse the commit info (if it isn't already parsed) and do the matching for the various fields as before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 12:56:44 +01:00
if {![info exists commitinfo($id)] && ![getcommit $id]} return
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
unmarkmatches
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
unselectline
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
normalline
$canv delete hover
# draw this line thicker than normal
set thickerline $id
gitk: Fix a bug in drawing the selected line as a thick line If you clicked on a line, so that it was drawn double-thickness, and then scrolled to bring on-screen a child that hadn't previously been drawn, the lines from it to the selected line were drawn single-thickness. This fixes it so they are drawn double-thickness. This also removes an unnecessary setting of phase in drawrest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 13:00:44 +01:00
drawlines $id
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
if {$isnew} {
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
set ymax [lindex [$canv cget -scrollregion] 3]
if {$ymax eq {}} return
set yfrac [lindex [$canv yview] 0]
set y [expr {$y + $yfrac * $ymax}]
}
set dirn [clickisonarrow $id $y]
if {$dirn ne {}} {
arrowjump $id $dirn $y
return
}
if {$isnew} {
addtohistory [list lineclick $x $y $id 0]
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
# fill the details pane with info about this line
$ctext conf -state normal
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
clear_ctext
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
settabs 0
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "[mc "Parent"]:\t"
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
$ctext insert end $id link0
setlink $id link0
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
set info $commitinfo($id)
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
$ctext insert end "\n\t[lindex $info 0]\n"
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "\t[mc "Author"]:\t[lindex $info 1]\n"
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set date [formatdate [lindex $info 2]]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "\t[mc "Date"]:\t$date\n"
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
set kids $children($curview,$id)
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
if {$kids ne {}} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "\n[mc "Children"]:"
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
set i 0
gitk: replace parent and children arrays with lists This will make it easier to switch between views efficiently, and turns out to be slightly faster as well. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-02 12:47:40 +02:00
foreach child $kids {
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
incr i
gitk: Further speedups Now we don't parse the commits as we are reading them, we just put commit data on a list as a blob, and instead parse the commit when we need the various parts of it, such as when a commit is drawn on the canvas. This makes searching a bit more interesting: now we scan through the commit blobs doing a string or regexp match to find commits that might match, then for those that might match, we parse the commit info (if it isn't already parsed) and do the matching for the various fields as before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 12:56:44 +01:00
if {![info exists commitinfo($child)] && ![getcommit $child]} continue
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
set info $commitinfo($child)
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
$ctext insert end "\n\t"
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
$ctext insert end $child link$i
setlink $child link$i
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
$ctext insert end "\n\t[lindex $info 0]"
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "\n\t[mc "Author"]:\t[lindex $info 1]"
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set date [formatdate [lindex $info 2]]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "\n\t[mc "Date"]:\t$date\n"
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
}
$ctext conf -state disabled
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
init_flist {}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
proc normalline {} {
global thickerline
if {[info exists thickerline]} {
gitk: Fix a bug in drawing the selected line as a thick line If you clicked on a line, so that it was drawn double-thickness, and then scrolled to bring on-screen a child that hadn't previously been drawn, the lines from it to the selected line were drawn single-thickness. This fixes it so they are drawn double-thickness. This also removes an unnecessary setting of phase in drawrest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 13:00:44 +01:00
set id $thickerline
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
unset thickerline
gitk: Fix a bug in drawing the selected line as a thick line If you clicked on a line, so that it was drawn double-thickness, and then scrolled to bring on-screen a child that hadn't previously been drawn, the lines from it to the selected line were drawn single-thickness. This fixes it so they are drawn double-thickness. This also removes an unnecessary setting of phase in drawrest. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-03-02 13:00:44 +01:00
drawlines $id
Draw selected graph line thicker and make arrowheads active.
2005-08-30 02:57:11 +02:00
}
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
proc selbyid {id} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global curview
if {[commitinview $id $curview]} {
selectline [rowofcommit $id] 1
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
}
proc mstime {} {
global startmstime
if {![info exists startmstime]} {
set startmstime [clock clicks -milliseconds]
}
return [format "%.3f" [expr {([clock click -milliseconds] - $startmstime) / 1000.0}]]
}
proc rowmenu {x y id} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global rowctxmenu selectedline rowmenuid curview
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
global nullid nullid2 fakerowmenu mainhead markedid
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
stopfinding
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set rowmenuid $id
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {} || [rowofcommit $id] eq $selectedline} {
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
set state disabled
} else {
set state normal
}
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
if {$id ne $nullid && $id ne $nullid2} {
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set menu $rowctxmenu
gitk: Disable "Reset %s branch to here" when on a detached head When we are on a detached head - since gitk does not display where we are - reset has no sense, so disable the relevant line on the context menu, and point out to the user that we are on a detached head. Otherwise, a reset from gitk when on a detached head returns the error: can't read "headids()": no such element in array can't read "headids()": no such element in array while executing "removehead $headids($name) $name" (procedure "movehead" line 4) invoked from within "movehead $newhead $mainhead" (procedure "readresetstat" line 20) invoked from within "readresetstat file4" ("eval" body line 1) invoked from within "eval $script" (procedure "dorunq" line 9) invoked from within "dorunq" ("after" script) [paulus@samba.org: changed menu item to "Detached head: can't reset"] Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-02 17:46:20 +02:00
if {$mainhead ne {}} {
gitk: Ensure that "Reset branch" menu entry is enabled Consider this sequence of events: 1. Detach HEAD and fire up gitk 2. Call the context menu on some commit. Notice that the last menu entry says "Detached HEAD: can't reset" and it is disabled. 3. Now checkout some regular branch (e.g. 'master') using the context menu. 4. Call the context menu again on some commit. Previously, at this point the last menu entry said "Reset master branch to here", but it was still disabled. With this fix it is now enabled again. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-03 13:43:20 +01:00
$menu entryconfigure 7 -label [mc "Reset %s branch to here" $mainhead] -state normal
gitk: Disable "Reset %s branch to here" when on a detached head When we are on a detached head - since gitk does not display where we are - reset has no sense, so disable the relevant line on the context menu, and point out to the user that we are on a detached head. Otherwise, a reset from gitk when on a detached head returns the error: can't read "headids()": no such element in array can't read "headids()": no such element in array while executing "removehead $headids($name) $name" (procedure "movehead" line 4) invoked from within "movehead $newhead $mainhead" (procedure "readresetstat" line 20) invoked from within "readresetstat file4" ("eval" body line 1) invoked from within "eval $script" (procedure "dorunq" line 9) invoked from within "dorunq" ("after" script) [paulus@samba.org: changed menu item to "Detached head: can't reset"] Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-02 17:46:20 +02:00
} else {
$menu entryconfigure 7 -label [mc "Detached head: can't reset" $mainhead] -state disabled
}
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
if {[info exists markedid] && $markedid ne $id} {
$menu entryconfigure 9 -state normal
$menu entryconfigure 10 -state normal
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
$menu entryconfigure 11 -state normal
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
} else {
$menu entryconfigure 9 -state disabled
$menu entryconfigure 10 -state disabled
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
$menu entryconfigure 11 -state disabled
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
}
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
} else {
set menu $fakerowmenu
}
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
$menu entryconfigure [mca "Diff this -> selected"] -state $state
$menu entryconfigure [mca "Diff selected -> this"] -state $state
$menu entryconfigure [mca "Make patch"] -state $state
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
tk_popup $menu $x $y
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
proc markhere {} {
global rowmenuid markedid canv
set markedid $rowmenuid
make_idmark $markedid
}
proc gotomark {} {
global markedid
if {[info exists markedid]} {
selbyid $markedid
}
}
proc replace_by_kids {l r} {
global curview children
set id [commitonrow $r]
set l [lreplace $l 0 0]
foreach kid $children($curview,$id) {
lappend l [rowofcommit $kid]
}
return [lsort -integer -decreasing -unique $l]
}
proc find_common_desc {} {
global markedid rowmenuid curview children
if {![info exists markedid]} return
if {![commitinview $markedid $curview] ||
![commitinview $rowmenuid $curview]} return
#set t1 [clock clicks -milliseconds]
set l1 [list [rowofcommit $markedid]]
set l2 [list [rowofcommit $rowmenuid]]
while 1 {
set r1 [lindex $l1 0]
set r2 [lindex $l2 0]
if {$r1 eq {} || $r2 eq {}} break
if {$r1 == $r2} {
selectline $r1 1
break
}
if {$r1 > $r2} {
set l1 [replace_by_kids $l1 $r1]
} else {
set l2 [replace_by_kids $l2 $r2]
}
}
#set t2 [clock clicks -milliseconds]
#puts "took [expr {$t2-$t1}]ms"
}
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
proc compare_commits {} {
global markedid rowmenuid curview children
if {![info exists markedid]} return
if {![commitinview $markedid $curview]} return
addtohistory [list do_cmp_commits $markedid $rowmenuid]
do_cmp_commits $markedid $rowmenuid
}
proc getpatchid {id} {
global patchids
if {![info exists patchids($id)]} {
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
set cmd [diffcmd [list $id] {-p --root}]
# trim off the initial "|"
set cmd [lrange $cmd 1 end]
if {[catch {
set x [eval exec $cmd | git patch-id]
set patchids($id) [lindex $x 0]
}]} {
set patchids($id) "error"
}
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
}
return $patchids($id)
}
proc do_cmp_commits {a b} {
global ctext curview parents children patchids commitinfo
$ctext conf -state normal
clear_ctext
init_flist {}
for {set i 0} {$i < 100} {incr i} {
set skipa 0
set skipb 0
if {[llength $parents($curview,$a)] > 1} {
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
appendshortlink $a [mc "Skipping merge commit "] "\n"
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
set skipa 1
} else {
set patcha [getpatchid $a]
}
if {[llength $parents($curview,$b)] > 1} {
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
appendshortlink $b [mc "Skipping merge commit "] "\n"
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
set skipb 1
} else {
set patchb [getpatchid $b]
}
if {!$skipa && !$skipb} {
set heada [lindex $commitinfo($a) 0]
set headb [lindex $commitinfo($b) 0]
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
if {$patcha eq "error"} {
appendshortlink $a [mc "Error getting patch ID for "] \
[mc " - stopping\n"]
break
}
if {$patchb eq "error"} {
appendshortlink $b [mc "Error getting patch ID for "] \
[mc " - stopping\n"]
break
}
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
if {$patcha eq $patchb} {
if {$heada eq $headb} {
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
appendshortlink $a [mc "Commit "]
appendshortlink $b " == " " $heada\n"
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
} else {
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
appendshortlink $a [mc "Commit "] " $heada\n"
appendshortlink $b [mc " is the same patch as\n "] \
" $headb\n"
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
}
set skipa 1
set skipb 1
} else {
$ctext insert end "\n"
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
appendshortlink $a [mc "Commit "] " $heada\n"
appendshortlink $b [mc " differs from\n "] \
" $headb\n"
gitk: Show diff of commits at end of compare-commits output When comparing a string of commits, when we find two non-merge commits that differ, we now write the two commits to files and diff the files. This pulls out the logic for creating a temporary directory from external_diff into a separate procedure so that the new diffcommits procedure can use it. Because the diff command returns an exit status of 1 when the files differ, and Tcl treats that as an error, this adds catch {} around the close statements in getblobdiffline. At present this only removes the temporary files when gitk exits. It should remove them when the diff is done. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-07 02:08:21 +02:00
$ctext insert end [mc "Diff of commits:\n\n"]
$ctext conf -state disabled
update
diffcommits $a $b
return
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
}
}
if {$skipa} {
if {[llength $children($curview,$a)] != 1} {
$ctext insert end "\n"
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
appendshortlink $a [mc "Commit "] \
[mc " has %s children - stopping\n" \
[llength $children($curview,$a)]]
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
break
}
set a [lindex $children($curview,$a) 0]
}
if {$skipb} {
if {[llength $children($curview,$b)] != 1} {
gitk: Fix compare-commits function when we have local changes This fixes a bug in the compare-commits function added in commit 010509f2 ("gitk: Add a command to compare two strings of commits") where gitk would show an error dialog if the comparison of commits got to a fake commit (one showing local changes). It extends getpatchid to handle these fake commits by using [diffcmd] to get the git diff command variant to use, and also handles the situation where an error occurs. Now that we can have the fake commit IDs showing up, which are 00..00 and 00..01, the short ID is ambiguous. To make sure the links point to the right commit, this adds a new [appendshortlink] procedure which takes the full link destination, and uses that rather than appendwithlinks. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-21 14:22:31 +02:00
appendshortlink $b [mc "Commit "] \
[mc " has %s children - stopping\n" \
[llength $children($curview,$b)]]
gitk: Add a command to compare two strings of commits This adds a row context menu command to compare this commit and its descendants with the marked commit and its descendants. The results are shown in the bottom-left pane. Commits are compared by checking whether their headlines are the same and their patches have the same patch ID as generated by git patch-id. Merges are ignored and skipped over (as long as they have one descendant). If two commits have the same patch ID then the process will continue and compare their descendants, as long as they both have exactly one descendant. If either commit has 0 or 2 or more descendants, the comparison stops there. There is currently a limit of 100 comparisons. This can be useful for checking whether one string of commits is just a rebased version of another string of commits. Mark the end of one string (i.e. the oldest commit in the string) and invoke "Compare with marked commit" on the end of the other string. As this is implemented, the UI will be unresponsive while the results are being generated. This should be fixed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 14:10:20 +02:00
break
}
set b [lindex $children($curview,$b) 0]
}
}
$ctext conf -state disabled
}
gitk: Show diff of commits at end of compare-commits output When comparing a string of commits, when we find two non-merge commits that differ, we now write the two commits to files and diff the files. This pulls out the logic for creating a temporary directory from external_diff into a separate procedure so that the new diffcommits procedure can use it. Because the diff command returns an exit status of 1 when the files differ, and Tcl treats that as an error, this adds catch {} around the close statements in getblobdiffline. At present this only removes the temporary files when gitk exits. It should remove them when the diff is done. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-09-07 02:08:21 +02:00
proc diffcommits {a b} {
global diffcontext diffids blobdifffd diffinhdr
set tmpdir [gitknewtmpdir]
set fna [file join $tmpdir "commit-[string range $a 0 7]"]
set fnb [file join $tmpdir "commit-[string range $b 0 7]"]
if {[catch {
exec git diff-tree -p --pretty $a >$fna
exec git diff-tree -p --pretty $b >$fnb
} err]} {
error_popup [mc "Error writing commit to file: %s" $err]
return
}
if {[catch {
set fd [open "| diff -U$diffcontext $fna $fnb" r]
} err]} {
error_popup [mc "Error diffing commits: %s" $err]
return
}
set diffids [list commits $a $b]
set blobdifffd($diffids) $fd
set diffinhdr 0
filerun $fd [list getblobdiffline $fd $diffids]
}
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
proc diffvssel {dirn} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
global rowmenuid selectedline
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
if {$selectedline eq {}} return
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
if {$dirn} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set oldid [commitonrow $selectedline]
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
set newid $rowmenuid
} else {
set oldid $rowmenuid
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set newid [commitonrow $selectedline]
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
addtohistory [list doseldiff $oldid $newid]
doseldiff $oldid $newid
}
proc doseldiff {oldid newid} {
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
global ctext
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
global commitinfo
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
$ctext conf -state normal
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
clear_ctext
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
init_flist [mc "Top"]
$ctext insert end "[mc "From"] "
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
$ctext insert end $oldid link0
setlink $oldid link0
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
$ctext insert end "\n "
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
$ctext insert end [lindex $commitinfo($oldid) 0]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
$ctext insert end "\n\n[mc "To"] "
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
$ctext insert end $newid link1
setlink $newid link1
Better graph line details display and expand history coverage. Now the history remembers when we have clicked on a graph line and when we have asked for a diff between two commits, as well as when we have displayed a commit. The display when you click on a graph line now uses clickable SHA1 IDs instead of the embedded "Go" buttons. Also made the IDs clickable in the header for a diff between two commits.
2005-08-08 01:47:22 +02:00
$ctext insert end "\n "
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
$ctext insert end [lindex $commitinfo($newid) 0]
$ctext insert end "\n"
$ctext conf -state disabled
$ctext tag remove found 1.0 end
gitk: Fix diff this->selected and selected->this functions The change in 8b7e5d76e836396a097bb6f61cf930ea872a7bd3, which makes a couple of git-diff-tree calls supply only one id rather than two, fixes the display when showing what a single commit did with dense revlists, but broke the diff this->selected and diff selected->this right-click menu functions. Yann Dirson pointed this out and had a patch that fixed the diff menu functions by passing a "singlecommit" flag around. This fixes it a bit differently, by making the ids and diffids variables be either a single id, in the case of showing what a commit did, or {oldid newid}, in the case of the diff menu functions. That way we can just pass $ids to git-diff-tree as is. Most of the changes in fact are just reversing the order of ids in $ids and $diffids, because they used to be {child parent}, but git-diff-tree requires old id before new id. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-28 10:41:56 +01:00
startdiff [list $oldid $newid]
Add commit row context menu and handle left-click on graph lines Right-click on a context row now brings up a menu allowing the user to generate a diff between that row and the selected row. Left-click on a graph line shows the parent and children connected by the line in the details pane. Left-click on a circle in the graph selects that commit. Left-click elsewhere in the graph does nothing. When displaying a diff, the bottom-right file list box behaves slightly differently now; instead of eliding all other files' diffs, it now just scrolls the details pane so that the selected file's diff starts at the top of the pane. Since the diffs can be rather large, arrange for an update to be done every 100ms while reading diffs. Also removed the CVS revision keywords and bumped the version number to 1.2.
2005-06-25 07:39:21 +02:00
}
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
proc mkpatch {} {
global rowmenuid currentid commitinfo patchtop patchnum
if {![info exists currentid]} return
set oldid $currentid
set oldhead [lindex $commitinfo($oldid) 0]
set newid $rowmenuid
set newhead [lindex $commitinfo($newid) 0]
set top .patch
set patchtop $top
catch {destroy $top}
toplevel $top
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $top .
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.title -text [mc "Generate patch"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
grid $top.title - -pady 10
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.from -text [mc "From:"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.fromsha1 -width 40 -relief flat
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
$top.fromsha1 insert 0 $oldid
$top.fromsha1 conf -state readonly
grid $top.from $top.fromsha1 -sticky w
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.fromhead -width 60 -relief flat
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
$top.fromhead insert 0 $oldhead
$top.fromhead conf -state readonly
grid x $top.fromhead -sticky w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.to -text [mc "To:"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.tosha1 -width 40 -relief flat
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
$top.tosha1 insert 0 $newid
$top.tosha1 conf -state readonly
grid $top.to $top.tosha1 -sticky w
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.tohead -width 60 -relief flat
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
$top.tohead insert 0 $newhead
$top.tohead conf -state readonly
grid x $top.tohead -sticky w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.rev -text [mc "Reverse"] -command mkpatchrev -padx 5
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
grid $top.rev x -pady 10
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.flab -text [mc "Output file:"]
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
entry $top.fname -width 60
$top.fname insert 0 [file normalize "patch$patchnum.patch"]
incr patchnum
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
grid $top.flab $top.fname -sticky w
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
frame $top.buts
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.buts.gen -text [mc "Generate"] -command mkpatchgo
button $top.buts.can -text [mc "Cancel"] -command mkpatchcan
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Key-Return> mkpatchgo
bind $top <Key-Escape> mkpatchcan
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
grid $top.buts.gen $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
focus $top.fname
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
}
proc mkpatchrev {} {
global patchtop
set oldid [$patchtop.fromsha1 get]
set oldhead [$patchtop.fromhead get]
set newid [$patchtop.tosha1 get]
set newhead [$patchtop.tohead get]
foreach e [list fromsha1 fromhead tosha1 tohead] \
v [list $newid $newhead $oldid $oldhead] {
$patchtop.$e conf -state normal
$patchtop.$e delete 0 end
$patchtop.$e insert 0 $v
$patchtop.$e conf -state readonly
}
}
proc mkpatchgo {} {
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
global patchtop nullid nullid2
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
set oldid [$patchtop.fromsha1 get]
set newid [$patchtop.tosha1 get]
set fname [$patchtop.fname get]
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set cmd [diffcmd [list $oldid $newid] -p]
gitk: Fix bug in generating patches Commit 8f4893639129acfc866c71583317090aa2a46eab changed mkpatchgo to use diffcmd rather than constructing the diff command itself. Unfortunately diffcmd returns the command with a "|" as the first element (ready for use with open), but exec won't accept the "|". Thus we need to remove the "|". Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-15 04:08:38 +02:00
# trim off the initial "|"
set cmd [lrange $cmd 1 end]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
lappend cmd >$fname &
if {[catch {eval exec $cmd} err]} {
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
error_popup "[mc "Error creating patch:"] $err" $patchtop
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
}
catch {destroy $patchtop}
unset patchtop
}
proc mkpatchcan {} {
global patchtop
catch {destroy $patchtop}
unset patchtop
}
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
proc mktag {} {
global rowmenuid mktagtop commitinfo
set top .maketag
set mktagtop $top
catch {destroy $top}
toplevel $top
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $top .
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.title -text [mc "Create tag"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
grid $top.title - -pady 10
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.id -text [mc "ID:"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.sha1 -width 40 -relief flat
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
$top.sha1 insert 0 $rowmenuid
$top.sha1 conf -state readonly
grid $top.id $top.sha1 -sticky w
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.head -width 60 -relief flat
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
$top.head insert 0 [lindex $commitinfo($rowmenuid) 0]
$top.head conf -state readonly
grid x $top.head -sticky w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.tlab -text [mc "Tag name:"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.tag -width 60
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
grid $top.tlab $top.tag -sticky w
frame $top.buts
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.buts.gen -text [mc "Create"] -command mktaggo
button $top.buts.can -text [mc "Cancel"] -command mktagcan
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Key-Return> mktaggo
bind $top <Key-Escape> mktagcan
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
grid $top.buts.gen $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.tag
}
proc domktag {} {
global mktagtop env tagids idtags
set id [$mktagtop.sha1 get]
set tag [$mktagtop.tag get]
if {$tag == {}} {
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
error_popup [mc "No tag name specified"] $mktagtop
return 0
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
}
if {[info exists tagids($tag)]} {
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
error_popup [mc "Tag \"%s\" already exists" $tag] $mktagtop
return 0
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
}
if {[catch {
[PATCH] gitk: properly deal with tag names containing / (slash) When creating a tag through gitk, and the tag name includes a slash (or slashes), gitk errors out in a popup window. This patch makes gitk use 'git tag' to create the tag instead of modifying files in refs/tags/, which fixes the issue; if 'git tag' throws an error, gitk pops up with the error message. The problem was reported by Frédéric Brière through http://bugs.debian.org/464104 Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-11 11:57:40 +01:00
exec git tag $tag $id
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
} err]} {
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
error_popup "[mc "Error creating tag:"] $err" $mktagtop
return 0
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
}
set tagids($tag) $id
lappend idtags($id) $tag
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
redrawtags $id
gitk: Update preceding/following tag info when creating a tag Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-08 12:55:36 +02:00
addedtag $id
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
dispneartags 0
run refill_reflist
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
return 1
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
}
proc redrawtags {id} {
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
global canv linehtag idpos currentid curview cmitlisted markedid
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
global canvxmax iddrawn circleitem mainheadid circlecolors
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {![commitinview $id $curview]} return
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
if {![info exists iddrawn($id)]} return
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
set row [rowofcommit $id]
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
if {$id eq $mainheadid} {
set ofill yellow
} else {
set ofill [lindex $circlecolors $cmitlisted($curview,$id)]
}
$canv itemconf $circleitem($row) -fill $ofill
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
$canv delete tag.$id
set xt [eval drawtags $id $idpos($id)]
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
$canv coords $linehtag($id) $xt [lindex $idpos($id) 2]
set text [$canv itemcget $linehtag($id) -text]
set font [$canv itemcget $linehtag($id) -font]
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
set xr [expr {$xt + [font measure $font $text]}]
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
if {$xr > $canvxmax} {
set canvxmax $xr
setcanvscroll
}
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
if {[info exists currentid] && $currentid == $id} {
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
make_secsel $id
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
}
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
if {[info exists markedid] && $markedid eq $id} {
make_idmark $id
}
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
}
proc mktagcan {} {
global mktagtop
catch {destroy $mktagtop}
unset mktagtop
}
proc mktaggo {} {
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
if {![domktag]} return
Add a menu item for creating tags.
2005-06-27 14:56:40 +02:00
mktagcan
}
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
proc writecommit {} {
global rowmenuid wrcomtop commitinfo wrcomcmd
set top .writecommit
set wrcomtop $top
catch {destroy $top}
toplevel $top
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $top .
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.title -text [mc "Write commit to file"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
grid $top.title - -pady 10
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.id -text [mc "ID:"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.sha1 -width 40 -relief flat
$top.sha1 insert 0 $rowmenuid
$top.sha1 conf -state readonly
grid $top.id $top.sha1 -sticky w
entry $top.head -width 60 -relief flat
$top.head insert 0 [lindex $commitinfo($rowmenuid) 0]
$top.head conf -state readonly
grid x $top.head -sticky w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.clab -text [mc "Command:"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.cmd -width 60 -textvariable wrcomcmd
grid $top.clab $top.cmd -sticky w -pady 10
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.flab -text [mc "Output file:"]
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
entry $top.fname -width 60
$top.fname insert 0 [file normalize "commit-[string range $rowmenuid 0 6]"]
grid $top.flab $top.fname -sticky w
frame $top.buts
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.buts.gen -text [mc "Write"] -command wrcomgo
button $top.buts.can -text [mc "Cancel"] -command wrcomcan
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Key-Return> wrcomgo
bind $top <Key-Escape> wrcomcan
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
grid $top.buts.gen $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.fname
}
proc wrcomgo {} {
global wrcomtop
set id [$wrcomtop.sha1 get]
set cmd "echo $id | [$wrcomtop.cmd get]"
set fname [$wrcomtop.fname get]
if {[catch {exec sh -c $cmd >$fname &} err]} {
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
error_popup "[mc "Error writing commit:"] $err" $wrcomtop
Add a menu item for writing out a commit to a file. This just invokes git-diff-tree. Also changed the readonly entry widgets in the "write patch" and "generate tag" windows to have flat relief, so it doesn't look like you should be able to modify what's in them.
2005-06-29 01:47:48 +02:00
}
catch {destroy $wrcomtop}
unset wrcomtop
}
proc wrcomcan {} {
global wrcomtop
catch {destroy $wrcomtop}
unset wrcomtop
}
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
proc mkbranch {} {
global rowmenuid mkbrtop
set top .makebranch
catch {destroy $top}
toplevel $top
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $top .
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.title -text [mc "Create new branch"]
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
grid $top.title - -pady 10
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.id -text [mc "ID:"]
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
entry $top.sha1 -width 40 -relief flat
$top.sha1 insert 0 $rowmenuid
$top.sha1 conf -state readonly
grid $top.id $top.sha1 -sticky w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.nlab -text [mc "Name:"]
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
entry $top.name -width 40
grid $top.nlab $top.name -sticky w
frame $top.buts
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.buts.go -text [mc "Create"] -command [list mkbrgo $top]
button $top.buts.can -text [mc "Cancel"] -command "catch {destroy $top}"
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Key-Return> [list mkbrgo $top]
bind $top <Key-Escape> "catch {destroy $top}"
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
grid $top.buts.go $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.name
}
proc mkbrgo {top} {
global headids idheads
set name [$top.name get]
set id [$top.sha1 get]
gitk: Allow forcing branch creation if it already exists If gitk knows that the branch the user tries to create exists, it should ask whether it should overwrite it. This way the user can either decide to choose a new name, or move the head while preserving the reflog. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-08 09:05:35 +02:00
set cmdargs {}
set old_id {}
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
if {$name eq {}} {
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
error_popup [mc "Please specify a name for the new branch"] $top
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
return
}
gitk: Allow forcing branch creation if it already exists If gitk knows that the branch the user tries to create exists, it should ask whether it should overwrite it. This way the user can either decide to choose a new name, or move the head while preserving the reflog. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-08 09:05:35 +02:00
if {[info exists headids($name)]} {
if {![confirm_popup [mc \
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
"Branch '%s' already exists. Overwrite?" $name] $top]} {
gitk: Allow forcing branch creation if it already exists If gitk knows that the branch the user tries to create exists, it should ask whether it should overwrite it. This way the user can either decide to choose a new name, or move the head while preserving the reflog. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-08 09:05:35 +02:00
return
}
set old_id $headids($name)
lappend cmdargs -f
}
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
catch {destroy $top}
gitk: Allow forcing branch creation if it already exists If gitk knows that the branch the user tries to create exists, it should ask whether it should overwrite it. This way the user can either decide to choose a new name, or move the head while preserving the reflog. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-08 09:05:35 +02:00
lappend cmdargs $name $id
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
nowbusy newbranch
update
if {[catch {
gitk: Allow forcing branch creation if it already exists If gitk knows that the branch the user tries to create exists, it should ask whether it should overwrite it. This way the user can either decide to choose a new name, or move the head while preserving the reflog. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-08 09:05:35 +02:00
eval exec git branch $cmdargs
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
} err]} {
notbusy newbranch
error_popup $err
} else {
notbusy newbranch
gitk: Allow forcing branch creation if it already exists If gitk knows that the branch the user tries to create exists, it should ask whether it should overwrite it. This way the user can either decide to choose a new name, or move the head while preserving the reflog. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-08 09:05:35 +02:00
if {$old_id ne {}} {
movehead $id $name
movedhead $id $name
redrawtags $old_id
redrawtags $id
} else {
set headids($name) $id
lappend idheads($id) $name
addedhead $id $name
redrawtags $id
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
dispneartags 0
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
run refill_reflist
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
}
}
gitk: Make cherry-pick call git-citool on conflicts Now that git-gui has facilities to help users resolve conflicts, it makes sense to launch it from other GUI tools when they happen. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:47 +01:00
proc exec_citool {tool_args {baseid {}}} {
global commitinfo env
set save_env [array get env GIT_AUTHOR_*]
if {$baseid ne {}} {
if {![info exists commitinfo($baseid)]} {
getcommit $baseid
}
set author [lindex $commitinfo($baseid) 1]
set date [lindex $commitinfo($baseid) 2]
if {[regexp {^\s*(\S.*\S|\S)\s*<(.*)>\s*$} \
$author author name email]
&& $date ne {}} {
set env(GIT_AUTHOR_NAME) $name
set env(GIT_AUTHOR_EMAIL) $email
set env(GIT_AUTHOR_DATE) $date
}
}
eval exec git citool $tool_args &
array unset env GIT_AUTHOR_*
array set env $save_env
}
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
proc cherrypick {} {
gitk: Don't filter view arguments through git rev-parse Previously we passed the arguments indicating what commits the user wants to view through git rev-parse to get a list of IDs (positive and negative), then gave that to git log. This had a couple of problems, notably that --merge and --left-right didn't get handled properly. Instead we now just pass the original arguments to git log. When doing an update, we append --not followed by the list of commits we have seen that have no children, since we have got (or will get) their ancestors from the first git log. If the first git log isn't finished yet, we might get some duplicates from the second git log, but that doesn't cause any problem. Also get rid of the unused vnextroot variable. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-03 00:19:35 +01:00
global rowmenuid curview
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
global mainhead mainheadid
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set oldhead [exec git rev-parse HEAD]
set dheads [descheads $rowmenuid]
if {$dheads ne {} && [lsearch -exact $dheads $oldhead] >= 0} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
set ok [confirm_popup [mc "Commit %s is already\
included in branch %s -- really re-apply it?" \
[string range $rowmenuid 0 7] $mainhead]]
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
if {!$ok} return
}
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
nowbusy cherrypick [mc "Cherry-picking"]
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
update
# Unfortunately git-cherry-pick writes stuff to stderr even when
# no error occurs, and exec takes that as an indication of error...
if {[catch {exec sh -c "git cherry-pick -r $rowmenuid 2>&1"} err]} {
notbusy cherrypick
gitk: Make cherry-pick call git-citool on conflicts Now that git-gui has facilities to help users resolve conflicts, it makes sense to launch it from other GUI tools when they happen. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:47 +01:00
if {[regexp -line \
gitk: Improve cherry-pick error handling This adds to the regexps that are used to work out what sort of error we encountered in trying to do a cherry-pick so that it recognizes some additional common error messages. It adds a confirmation dialog when the error is a merge conflict so the user can choose whether or not to run git citool. Finally, it arranges to update the display after a cherry-pick failed so that any local changes made by the cherry-pick become visible. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-08 11:37:09 +01:00
{Entry '(.*)' (would be overwritten by merge|not uptodate)} \
$err msg fname]} {
error_popup [mc "Cherry-pick failed because of local changes\
to file '%s'.\nPlease commit, reset or stash\
your changes and try again." $fname]
} elseif {[regexp -line \
{^(CONFLICT \(.*\):|Automatic cherry-pick failed)} \
$err]} {
if {[confirm_popup [mc "Cherry-pick failed because of merge\
conflict.\nDo you wish to run git citool to\
resolve it?"]]} {
# Force citool to read MERGE_MSG
file delete [file join [gitdir] "GITGUI_MSG"]
exec_citool {} $rowmenuid
}
gitk: Make cherry-pick call git-citool on conflicts Now that git-gui has facilities to help users resolve conflicts, it makes sense to launch it from other GUI tools when they happen. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:47 +01:00
} else {
error_popup $err
}
gitk: Improve cherry-pick error handling This adds to the regexps that are used to work out what sort of error we encountered in trying to do a cherry-pick so that it recognizes some additional common error messages. It adds a confirmation dialog when the error is a merge conflict so the user can choose whether or not to run git citool. Finally, it arranges to update the display after a cherry-pick failed so that any local changes made by the cherry-pick become visible. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-08 11:37:09 +01:00
run updatecommits
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
return
}
set newhead [exec git rev-parse HEAD]
if {$newhead eq $oldhead} {
notbusy cherrypick
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
error_popup [mc "No changes committed"]
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
return
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
addnewchild $newhead $oldhead
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $oldhead $curview]} {
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
# XXX this isn't right if we have a path limit...
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
insertrow $newhead $oldhead $curview
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
if {$mainhead ne {}} {
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
movehead $newhead $mainhead
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
movedhead $newhead $mainhead
}
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
set mainheadid $newhead
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
redrawtags $oldhead
redrawtags $newhead
gitk: Select something appropriate on cherry-pick, branch reset and checkout This makes gitk select the new commit when cherry-picking, and select the new checked-out head when resetting or checking out a branch. This feels more natural because the user is usually more interested in that commit now than whatever was selected before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-15 12:16:32 +01:00
selbyid $newhead
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
}
notbusy cherrypick
}
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
proc resethead {} {
gitk: Fix cherry-picking to insert a real row not a fake row The insertrow/removerow functions were really only suitable for inserting/removing a fake row such as the ones used for showing the local changes. When used to insert a real new row from a cherry-pick, they left things in an inconsistent state which then caused various strange layout errors. This renames insertrow/removerow to insertfakerow/removefakerow and adds a new insertrow that does actually go to all the trouble of creating a new arc and setting it up. This is more work but keeps things consistent. This also fixes a bug where cherrypick was not setting mainheadid, and one where selectline wasn't always resulting in targetrow/id being set to the selected row/id. Also insert/removefakerow now adjust numcommits and call setcanvscroll. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-13 12:12:31 +01:00
global mainhead rowmenuid confirm_ok resettype
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
set confirm_ok 0
set w ".confirmreset"
toplevel $w
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $w .
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
wm title $w [mc "Confirm reset"]
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
message $w.m -text \
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
[mc "Reset branch %s to %s?" $mainhead [string range $rowmenuid 0 7]] \
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
-justify center -aspect 1000
pack $w.m -side top -fill x -padx 20 -pady 20
frame $w.f -relief sunken -border 2
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
message $w.f.rt -text [mc "Reset type:"] -aspect 1000
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
grid $w.f.rt -sticky w
set resettype mixed
radiobutton $w.f.soft -value soft -variable resettype -justify left \
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
-text [mc "Soft: Leave working tree and index untouched"]
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
grid $w.f.soft -sticky w
radiobutton $w.f.mixed -value mixed -variable resettype -justify left \
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
-text [mc "Mixed: Leave working tree untouched, reset index"]
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
grid $w.f.mixed -sticky w
radiobutton $w.f.hard -value hard -variable resettype -justify left \
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
-text [mc "Hard: Reset working tree and index\n(discard ALL local changes)"]
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
grid $w.f.hard -sticky w
pack $w.f -side top -fill x
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $w.ok -text [mc OK] -command "set confirm_ok 1; destroy $w"
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
pack $w.ok -side left -fill x -padx 20 -pady 20
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $w.cancel -text [mc Cancel] -command "destroy $w"
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $w <Key-Escape> [list destroy $w]
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
pack $w.cancel -side right -fill x -padx 20 -pady 20
bind $w <Visibility> "grab $w; focus $w"
tkwait window $w
if {!$confirm_ok} return
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
if {[catch {set fd [open \
gitk: Add a progress bar for checking out a head Now that git checkout reports progress when checking out files, we can use that to provide a progress bar in gitk. We re-use the green progress bar (formerly used when reading stuff in) for that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-12 02:18:38 +02:00
[list | git reset --$resettype $rowmenuid 2>@1] r]} err]} {
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
error_popup $err
} else {
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
dohidelocalchanges
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
filerun $fd [list readresetstat $fd]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
nowbusy reset [mc "Resetting"]
gitk: Select something appropriate on cherry-pick, branch reset and checkout This makes gitk select the new commit when cherry-picking, and select the new checked-out head when resetting or checking out a branch. This feels more natural because the user is usually more interested in that commit now than whatever was selected before. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-15 12:16:32 +01:00
selbyid $rowmenuid
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
}
}
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
proc readresetstat {fd} {
global mainhead mainheadid showlocalchanges rprogcoord
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
if {[gets $fd line] >= 0} {
if {[regexp {([0-9]+)% \(([0-9]+)/([0-9]+)\)} $line match p m n]} {
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
set rprogcoord [expr {1.0 * $m / $n}]
adjustprogress
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
}
return 1
}
gitk: Integrate the reset progress bar in the main frame This makes the reset function use a progress bar in the same location as the progress bars for reading in commits and for finding commits, instead of a progress bar in a separate detached window. The progress bar for resetting is red. This also puts "Resetting" in the status window while the reset is in progress. The setting of the status window is done through an extension of the interface used for setting the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 13:12:49 +02:00
set rprogcoord 0
adjustprogress
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
notbusy reset
if {[catch {close $fd} err]} {
error_popup $err
}
set oldhead $mainheadid
set newhead [exec git rev-parse HEAD]
if {$newhead ne $oldhead} {
movehead $newhead $mainhead
movedhead $newhead $mainhead
set mainheadid $newhead
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
redrawtags $oldhead
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
redrawtags $newhead
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
}
if {$showlocalchanges} {
doshowlocalchanges
}
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
return 0
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
}
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
# context menu for a head
proc headmenu {x y id head} {
gitk: Disable the head context menu entries for the checked-out branch Neither the "check out this branch" nor the "remove this branch" menu item can be used on the currently-checked out branch, so disable them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 09:08:35 +02:00
global headmenuid headmenuhead headctxmenu mainhead
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
gitk: Add progress bars for reading in stuff and for finding This uses the space formerly occupied by the find string entry field to make a status label (unused for now) and a canvas to display a couple of progress bars. The bar for reading in commits is a short green bar that oscillates back and forth as commits come in. The bar for showing the progress of a Find operation is yellow and advances from left to right. This also arranges to stop a Find operation if the user selects another commit or pops up a context menu, and fixes the "highlight this" popup menu items in the file list window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-27 03:00:25 +02:00
stopfinding
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
set headmenuid $id
set headmenuhead $head
gitk: Disable the head context menu entries for the checked-out branch Neither the "check out this branch" nor the "remove this branch" menu item can be used on the currently-checked out branch, so disable them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 09:08:35 +02:00
set state normal
if {$head eq $mainhead} {
set state disabled
}
$headctxmenu entryconfigure 0 -state $state
$headctxmenu entryconfigure 1 -state $state
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
tk_popup $headctxmenu $x $y
}
proc cobranch {} {
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
global headmenuid headmenuhead headids
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
global showlocalchanges
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
# check the tree is clean first??
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
nowbusy checkout [mc "Checking out"]
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
update
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
dohidelocalchanges
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
if {[catch {
gitk: Add a progress bar for checking out a head Now that git checkout reports progress when checking out files, we can use that to provide a progress bar in gitk. We re-use the green progress bar (formerly used when reading stuff in) for that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-12 02:18:38 +02:00
set fd [open [list | git checkout $headmenuhead 2>@1] r]
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
} err]} {
notbusy checkout
error_popup $err
gitk: Add a progress bar for checking out a head Now that git checkout reports progress when checking out files, we can use that to provide a progress bar in gitk. We re-use the green progress bar (formerly used when reading stuff in) for that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-12 02:18:38 +02:00
if {$showlocalchanges} {
dodiffindex
}
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
} else {
gitk: Add a progress bar for checking out a head Now that git checkout reports progress when checking out files, we can use that to provide a progress bar in gitk. We re-use the green progress bar (formerly used when reading stuff in) for that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-12 02:18:38 +02:00
filerun $fd [list readcheckoutstat $fd $headmenuhead $headmenuid]
}
}
proc readcheckoutstat {fd newhead newheadid} {
global mainhead mainheadid headids showlocalchanges progresscoords
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
global viewmainheadid curview
gitk: Add a progress bar for checking out a head Now that git checkout reports progress when checking out files, we can use that to provide a progress bar in gitk. We re-use the green progress bar (formerly used when reading stuff in) for that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-12 02:18:38 +02:00
if {[gets $fd line] >= 0} {
if {[regexp {([0-9]+)% \(([0-9]+)/([0-9]+)\)} $line match p m n]} {
set progresscoords [list 0 [expr {1.0 * $m / $n}]]
adjustprogress
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
}
gitk: Add a progress bar for checking out a head Now that git checkout reports progress when checking out files, we can use that to provide a progress bar in gitk. We re-use the green progress bar (formerly used when reading stuff in) for that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-12 02:18:38 +02:00
return 1
}
set progresscoords {0 0}
adjustprogress
notbusy checkout
if {[catch {close $fd} err]} {
error_popup $err
}
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
set oldmainid $mainheadid
gitk: Add a progress bar for checking out a head Now that git checkout reports progress when checking out files, we can use that to provide a progress bar in gitk. We re-use the green progress bar (formerly used when reading stuff in) for that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-12 02:18:38 +02:00
set mainhead $newhead
set mainheadid $newheadid
gitk: Show local changes properly when we have a path limit Since gitk looks for the HEAD commit to attach the fake commits for local changes to, we can miss out on seeing the fake commits if we have a path limit and the HEAD commit doesn't alter any of the files in the path limit. This fixes it by running git rev-list -1 $head -- $paths if we have a path limit, and taking the result of that as the commit to attach the fake commits to. This means that we can be attaching the fake commits to a different commit in each view, so we use a new $viewmainhead($view) for that. This also fixes a buglet where updatecommits would only fix up the fake commits if the HEAD changed since the last call to updatecommits, whereas it should fix them up if the HEAD has changed since this view was last created or updated. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-18 09:54:14 +01:00
set viewmainheadid($curview) $newheadid
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
redrawtags $oldmainid
gitk: Add a progress bar for checking out a head Now that git checkout reports progress when checking out files, we can use that to provide a progress bar in gitk. We re-use the green progress bar (formerly used when reading stuff in) for that. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-12 02:18:38 +02:00
redrawtags $newheadid
selbyid $newheadid
gitk: Add a "reset branch to here" row context-menu operation This adds an entry to the menu that comes up when the user does a right-click on a row. The new entry allows the user to reset the currently checked-out head to the commit for the row that they did the right-click on. The user has to select what type of reset to do, and confirm the reset, via a dialog box that pops up. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-19 02:09:06 +02:00
if {$showlocalchanges} {
dodiffindex
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
}
}
proc rmbranch {} {
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
global headmenuid headmenuhead mainhead
gitk: Fix warning when removing a branch When we had two heads on the same commit, and the user tried to remove one of them, gitk was sometimes incorrectly saying that the commits on that branch weren't on any other branch. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-15 02:09:47 +02:00
global idheads
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
set head $headmenuhead
set id $headmenuid
gitk: Disable the head context menu entries for the checked-out branch Neither the "check out this branch" nor the "remove this branch" menu item can be used on the currently-checked out branch, so disable them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 09:08:35 +02:00
# this check shouldn't be needed any more...
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
if {$head eq $mainhead} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
error_popup [mc "Cannot delete the currently checked-out branch"]
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
return
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set dheads [descheads $id]
gitk: Fix bug in fix for warning when removing a branch My fix in commit b1054ac985aebc90c0a78202dab8477b74d7818a was only half-right, since it ignored the case where the descendent heads of the head being removed correspond to two or more different commits. This fixes it. Reported by Mark Levedahl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-17 09:57:31 +02:00
if {[llength $dheads] == 1 && $idheads($dheads) eq $head} {
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
# the stuff on this branch isn't on any other branch
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
if {![confirm_popup [mc "The commits on branch %s aren't on any other\
branch.\nReally delete branch %s?" $head $head]]} return
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
}
nowbusy rmbranch
update
if {[catch {exec git branch -D $head} err]} {
notbusy rmbranch
error_popup $err
return
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
removehead $id $head
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
removedhead $id $head
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
redrawtags $id
notbusy rmbranch
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
dispneartags 0
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
run refill_reflist
}
# Display a list of tags and heads
proc showrefs {} {
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
global showrefstop bgcolor fgcolor selectbgcolor
global bglist fglist reflistfilter reflist maincursor
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
set top .showrefs
set showrefstop $top
if {[winfo exists $top]} {
raise $top
refill_reflist
return
}
toplevel $top
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
wm title $top [mc "Tags and heads: %s" [file tail [pwd]]]
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $top .
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
text $top.list -background $bgcolor -foreground $fgcolor \
gitk: Use named fonts instead of the font specification This replaces the use of $mainfont, $textfont and $uifont with named fonts called mainfont, textfont and uifont. We also have variants called mainfontbold and textfontbold. This makes it much easier to make sure font size changes are reflected everywhere they should be, since configuring a named font automatically changes all the widgets that are using that font. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-04 14:27:13 +02:00
-selectbackground $selectbgcolor -font mainfont \
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
-xscrollcommand "$top.xsb set" -yscrollcommand "$top.ysb set" \
-width 30 -height 20 -cursor $maincursor \
-spacing1 1 -spacing3 1 -state disabled
$top.list tag configure highlight -background $selectbgcolor
lappend bglist $top.list
lappend fglist $top.list
scrollbar $top.ysb -command "$top.list yview" -orient vertical
scrollbar $top.xsb -command "$top.list xview" -orient horizontal
grid $top.list $top.ysb -sticky nsew
grid $top.xsb x -sticky ew
frame $top.f
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
label $top.f.l -text "[mc "Filter"]: "
entry $top.f.e -width 20 -textvariable reflistfilter
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
set reflistfilter "*"
trace add variable reflistfilter write reflistfilter_change
pack $top.f.e -side right -fill x -expand 1
pack $top.f.l -side left
grid $top.f - -sticky ew -pady 2
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
button $top.close -command [list destroy $top] -text [mc "Close"]
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Key-Escape> [list destroy $top]
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
grid $top.close -
grid columnconfigure $top 0 -weight 1
grid rowconfigure $top 0 -weight 1
bind $top.list <1> {break}
bind $top.list <B1-Motion> {break}
bind $top.list <ButtonRelease-1> {sel_reflist %W %x %y; break}
set reflist {}
refill_reflist
}
proc sel_reflist {w x y} {
global showrefstop reflist headids tagids otherrefids
if {![winfo exists $showrefstop]} return
set l [lindex [split [$w index "@$x,$y"] "."] 0]
set ref [lindex $reflist [expr {$l-1}]]
set n [lindex $ref 0]
switch -- [lindex $ref 1] {
"H" {selbyid $headids($n)}
"T" {selbyid $tagids($n)}
"o" {selbyid $otherrefids($n)}
}
$showrefstop.list tag add highlight $l.0 "$l.0 lineend"
}
proc unsel_reflist {} {
global showrefstop
if {![info exists showrefstop] || ![winfo exists $showrefstop]} return
$showrefstop.list tag remove highlight 0.0 end
}
proc reflistfilter_change {n1 n2 op} {
global reflistfilter
after cancel refill_reflist
after 200 refill_reflist
}
proc refill_reflist {} {
global reflist reflistfilter showrefstop headids tagids otherrefids
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
global curview
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
if {![info exists showrefstop] || ![winfo exists $showrefstop]} return
set refs {}
foreach n [array names headids] {
if {[string match $reflistfilter $n]} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $headids($n) $curview]} {
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
lappend refs [list $n H]
} else {
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
interestedin $headids($n) {run refill_reflist}
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
}
}
}
foreach n [array names tagids] {
if {[string match $reflistfilter $n]} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $tagids($n) $curview]} {
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
lappend refs [list $n T]
} else {
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
interestedin $tagids($n) {run refill_reflist}
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
}
}
}
foreach n [array names otherrefids] {
if {[string match $reflistfilter $n]} {
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
if {[commitinview $otherrefids($n) $curview]} {
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
lappend refs [list $n o]
} else {
gitk: Turn short SHA1 names into links too This changes the link detection logic to accept strings of between 6 and 40 hex characters as a possible SHA1 ID of another commit, rather than insisting on seeing the full 40 hex characters. To make the logic that turns a possible link into an actual link work with abbreviated IDs, this changes the way the commitinterest array is used, and puts the code that deals with it in a pair of new functions. The commitinterest array is now indexed by just the first 4 characters of the interesting SHA1 ID, and each element is a list of id + command pairs. This also pulls out the logic for expanding an abbreviated SHA1 to the list of matching full IDs into its own function (the way it is done is still the same slow way it was done before, which should be improved some day). This also fixes the bug where clicking on a link would take you to the wrong commit if the line number of the target had changed since the link was made. This is based on a patch by Linus Torvalds, but totally rewritten by me. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-21 01:18:12 +02:00
interestedin $otherrefids($n) {run refill_reflist}
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
}
}
}
set refs [lsort -index 0 $refs]
if {$refs eq $reflist} return
# Update the contents of $showrefstop.list according to the
# differences between $reflist (old) and $refs (new)
$showrefstop.list conf -state normal
$showrefstop.list insert end "\n"
set i 0
set j 0
while {$i < [llength $reflist] || $j < [llength $refs]} {
if {$i < [llength $reflist]} {
if {$j < [llength $refs]} {
set cmp [string compare [lindex $reflist $i 0] \
[lindex $refs $j 0]]
if {$cmp == 0} {
set cmp [string compare [lindex $reflist $i 1] \
[lindex $refs $j 1]]
}
} else {
set cmp -1
}
} else {
set cmp 1
}
switch -- $cmp {
-1 {
$showrefstop.list delete "[expr {$j+1}].0" "[expr {$j+2}].0"
incr i
}
0 {
incr i
incr j
}
1 {
set l [expr {$j + 1}]
$showrefstop.list image create $l.0 -align baseline \
-image reficon-[lindex $refs $j 1] -padx 2
$showrefstop.list insert $l.1 "[lindex $refs $j 0]\n"
incr j
}
}
}
set reflist $refs
# delete last newline
$showrefstop.list delete end-2c end-1c
$showrefstop.list conf -state disabled
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
}
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
# Stuff for finding nearby tags
proc getallcommits {} {
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
global allcommits nextarc seeds allccache allcwait cachedarcs allcupdate
global idheads idtags idotherrefs allparents tagobjid
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
gitk: Fix bug causing Tcl error when updating graph If "Show nearby tags" is turned off, selecting "Update" from the File menu will cause a Tcl error. This fixes it. The problem was that we were calling regetallcommits unconditionally, but it assumed that getallcommits had been called previously. This also restructures {re,}getallcommits to be a bit simpler. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-13 07:02:02 +02:00
if {![info exists allcommits]} {
set nextarc 0
set allcommits 0
set seeds {}
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
set allcwait 0
set cachedarcs 0
set allccache [file join [gitdir] "gitk.cache"]
if {![catch {
set f [open $allccache r]
set allcwait 1
getcache $f
}]} return
gitk: Fix bug causing Tcl error when updating graph If "Show nearby tags" is turned off, selecting "Update" from the File menu will cause a Tcl error. This fixes it. The problem was that we were calling regetallcommits unconditionally, but it assumed that getallcommits had been called previously. This also restructures {re,}getallcommits to be a bit simpler. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-13 07:02:02 +02:00
}
gitk: Re-read the descendent/ancestor tag & head info on update Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-07 01:19:45 +02:00
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
if {$allcwait} {
return
}
set cmd [list | git rev-list --parents]
set allcupdate [expr {$seeds ne {}}]
if {!$allcupdate} {
set ids "--all"
} else {
set refs [concat [array names idheads] [array names idtags] \
[array names idotherrefs]]
set ids {}
set tagobjs {}
foreach name [array names tagobjid] {
lappend tagobjs $tagobjid($name)
}
foreach id [lsort -unique $refs] {
if {![info exists allparents($id)] &&
[lsearch -exact $tagobjs $id] < 0} {
lappend ids $id
}
}
if {$ids ne {}} {
foreach id $seeds {
lappend ids "^$id"
}
}
}
if {$ids ne {}} {
set fd [open [concat $cmd $ids] r]
fconfigure $fd -blocking 0
incr allcommits
nowbusy allcommits
filerun $fd [list getallclines $fd]
} else {
dispneartags 0
gitk: Re-read the descendent/ancestor tag & head info on update Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-07 01:19:45 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
}
# Since most commits have 1 parent and 1 child, we group strings of
# such commits into "arcs" joining branch/merge points (BMPs), which
# are commits that either don't have 1 parent or don't have 1 child.
#
# arcnos(id) - incoming arcs for BMP, arc we're on for other nodes
# arcout(id) - outgoing arcs for BMP
# arcids(a) - list of IDs on arc including end but not start
# arcstart(a) - BMP ID at start of arc
# arcend(a) - BMP ID at end of arc
# growing(a) - arc a is still growing
# arctags(a) - IDs out of arcids (excluding end) that have tags
# archeads(a) - IDs out of arcids (excluding end) that have heads
# The start of an arc is at the descendent end, so "incoming" means
# coming from descendents, and "outgoing" means going towards ancestors.
proc getallclines {fd} {
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
global allparents allchildren idtags idheads nextarc
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
global arcnos arcids arctags arcout arcend arcstart archeads growing
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
global seeds allcommits cachedarcs allcupdate
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set nid 0
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
while {[incr nid] <= 1000 && [gets $fd line] >= 0} {
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set id [lindex $line 0]
if {[info exists allparents($id)]} {
# seen it already
continue
}
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
set cachedarcs 0
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set olds [lrange $line 1 end]
set allparents($id) $olds
if {![info exists allchildren($id)]} {
set allchildren($id) {}
set arcnos($id) {}
lappend seeds $id
} else {
set a $arcnos($id)
if {[llength $olds] == 1 && [llength $a] == 1} {
lappend arcids($a) $id
if {[info exists idtags($id)]} {
lappend arctags($a) $id
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {[info exists idheads($id)]} {
lappend archeads($a) $id
}
if {[info exists allparents($olds)]} {
# seen parent already
if {![info exists arcout($olds)]} {
splitarc $olds
}
lappend arcids($a) $olds
set arcend($a) $olds
unset growing($a)
}
lappend allchildren($olds) $id
lappend arcnos($olds) $a
continue
}
}
foreach a $arcnos($id) {
lappend arcids($a) $id
set arcend($a) $id
unset growing($a)
}
set ao {}
foreach p $olds {
lappend allchildren($p) $id
set a [incr nextarc]
set arcstart($a) $id
set archeads($a) {}
set arctags($a) {}
set archeads($a) {}
set arcids($a) {}
lappend ao $a
set growing($a) 1
if {[info exists allparents($p)]} {
# seen it already, may need to make a new branch
if {![info exists arcout($p)]} {
splitarc $p
}
lappend arcids($a) $p
set arcend($a) $p
unset growing($a)
}
lappend arcnos($p) $a
}
set arcout($id) $ao
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
}
gitk: Fix bug causing nearby tags/heads to sometimes not be displayed When we compute descendent heads and descendent/ancestor tags, we cache the results. We need to be careful to invalidate the cache when we add stuff to the graph. Also make sure that when we cache descendent heads for a node we only cache the heads that are actually descendents of that node. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-18 14:39:21 +02:00
if {$nid > 0} {
global cached_dheads cached_dtags cached_atags
catch {unset cached_dheads}
catch {unset cached_dtags}
catch {unset cached_atags}
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
if {![eof $fd]} {
return [expr {$nid >= 1000? 2: 1}]
}
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
set cacheok 1
if {[catch {
fconfigure $fd -blocking 1
close $fd
} err]} {
# got an error reading the list of commits
# if we were updating, try rereading the whole thing again
if {$allcupdate} {
incr allcommits -1
dropcache $err
return
}
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
error_popup "[mc "Error reading commit topology information;\
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
branch and preceding/following tag information\
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
will be incomplete."]\n($err)"
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
set cacheok 0
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {[incr allcommits -1] == 0} {
notbusy allcommits
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
if {$cacheok} {
run savecache
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
}
dispneartags 0
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
proc recalcarc {a} {
global arctags archeads arcids idtags idheads
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set at {}
set ah {}
foreach id [lrange $arcids($a) 0 end-1] {
if {[info exists idtags($id)]} {
lappend at $id
}
if {[info exists idheads($id)]} {
lappend ah $id
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set arctags($a) $at
set archeads($a) $ah
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
proc splitarc {p} {
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
global arcnos arcids nextarc arctags archeads idtags idheads
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
global arcstart arcend arcout allparents growing
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set a $arcnos($p)
if {[llength $a] != 1} {
puts "oops splitarc called but [llength $a] arcs already"
return
}
set a [lindex $a 0]
set i [lsearch -exact $arcids($a) $p]
if {$i < 0} {
puts "oops splitarc $p not in arc $a"
return
}
set na [incr nextarc]
if {[info exists arcend($a)]} {
set arcend($na) $arcend($a)
} else {
set l [lindex $allparents([lindex $arcids($a) end]) 0]
set j [lsearch -exact $arcnos($l) $a]
set arcnos($l) [lreplace $arcnos($l) $j $j $na]
}
set tail [lrange $arcids($a) [expr {$i+1}] end]
set arcids($a) [lrange $arcids($a) 0 $i]
set arcend($a) $p
set arcstart($na) $p
set arcout($p) $na
set arcids($na) $tail
if {[info exists growing($a)]} {
set growing($na) 1
unset growing($a)
}
foreach id $tail {
if {[llength $arcnos($id)] == 1} {
set arcnos($id) $na
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
} else {
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set j [lsearch -exact $arcnos($id) $a]
set arcnos($id) [lreplace $arcnos($id) $j $j $na]
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
}
# reconstruct tags and heads lists
if {$arctags($a) ne {} || $archeads($a) ne {}} {
recalcarc $a
recalcarc $na
} else {
set arctags($na) {}
set archeads($na) {}
}
}
# Update things for a new commit added that is a child of one
# existing commit. Used when cherry-picking.
proc addnewchild {id p} {
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
global allparents allchildren idtags nextarc
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
global arcnos arcids arctags arcout arcend arcstart archeads growing
gitk: Fix bug causing undefined variable error when cherry-picking When "Show nearby tags" is turned off and the user did a cherry-pick, we were trying to access variables relating to the descendent/ancestor tag & head computations in addnewchild though they hadn't been set. This makes sure we don't do that. Reported by Johannes Sixt. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 14:41:34 +02:00
global seeds allcommits
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
gitk: Avoid an error when cherry-picking if HEAD has moved on This fixes an error reported by Adam Piątyszek: if the current HEAD is not in the graph that gitk knows about when we do a cherry-pick using gitk, then gitk hits an error when trying to update its internal representation of the topology. This avoids the error by not doing that update if the HEAD before the cherry-pick was a commit that gitk doesn't know about. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-20 14:10:52 +02:00
if {![info exists allcommits] || ![info exists arcnos($p)]} return
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set allparents($id) [list $p]
set allchildren($id) {}
set arcnos($id) {}
lappend seeds $id
lappend allchildren($p) $id
set a [incr nextarc]
set arcstart($a) $id
set archeads($a) {}
set arctags($a) {}
set arcids($a) [list $p]
set arcend($a) $p
if {![info exists arcout($p)]} {
splitarc $p
}
lappend arcnos($p) $a
set arcout($id) [list $a]
}
gitk: Add a cache for the topology info This adds code to write out the topology information used to determine precedes/follows and branch information into a cache file (~3.5MB for the kernel tree). At startup we read the cache file and then do a git rev-list to update it, which is fast because we exclude all commits in the cache that have no children and commits reachable from them (which amounts to everything in the cache). If one of those commits without children no longer exists, then git rev-list will give an error, whereupon we throw away the cache and read in the whole tree again. This gives a significant speedup in the startup time for gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-30 13:54:17 +02:00
# This implements a cache for the topology information.
# The cache saves, for each arc, the start and end of the arc,
# the ids on the arc, and the outgoing arcs from the end.
proc readcache {f} {
global arcnos arcids arcout arcstart arcend arctags archeads nextarc
global idtags idheads allparents cachedarcs possible_seeds seeds growing
global allcwait
set a $nextarc
set lim $cachedarcs
if {$lim - $a > 500} {
set lim [expr {$a + 500}]
}
if {[catch {
if {$a == $lim} {
# finish reading the cache and setting up arctags, etc.
set line [gets $f]
if {$line ne "1"} {error "bad final version"}
close $f
foreach id [array names idtags] {
if {[info exists arcnos($id)] && [llength $arcnos($id)] == 1 &&
[llength $allparents($id)] == 1} {
set a [lindex $arcnos($id) 0]
if {$arctags($a) eq {}} {
recalcarc $a
}
}
}
foreach id [array names idheads] {
if {[info exists arcnos($id)] && [llength $arcnos($id)] == 1 &&
[llength $allparents($id)] == 1} {
set a [lindex $arcnos($id) 0]
if {$archeads($a) eq {}} {
recalcarc $a
}
}
}
foreach id [lsort -unique $possible_seeds] {
if {$arcnos($id) eq {}} {
lappend seeds $id
}
}
set allcwait 0
} else {
while {[incr a] <= $lim} {
set line [gets $f]
if {[llength $line] != 3} {error "bad line"}
set s [lindex $line 0]
set arcstart($a) $s
lappend arcout($s) $a
if {![info exists arcnos($s)]} {
lappend possible_seeds $s
set arcnos($s) {}
}
set e [lindex $line 1]
if {$e eq {}} {
set growing($a) 1
} else {
set arcend($a) $e
if {![info exists arcout($e)]} {
set arcout($e) {}
}
}
set arcids($a) [lindex $line 2]
foreach id $arcids($a) {
lappend allparents($s) $id
set s $id
lappend arcnos($id) $a
}
if {![info exists allparents($s)]} {
set allparents($s) {}
}
set arctags($a) {}
set archeads($a) {}
}
set nextarc [expr {$a - 1}]
}
} err]} {
dropcache $err
return 0
}
if {!$allcwait} {
getallcommits
}
return $allcwait
}
proc getcache {f} {
global nextarc cachedarcs possible_seeds
if {[catch {
set line [gets $f]
if {[llength $line] != 2 || [lindex $line 0] ne "1"} {error "bad version"}
# make sure it's an integer
set cachedarcs [expr {int([lindex $line 1])}]
if {$cachedarcs < 0} {error "bad number of arcs"}
set nextarc 0
set possible_seeds {}
run readcache $f
} err]} {
dropcache $err
}
return 0
}
proc dropcache {err} {
global allcwait nextarc cachedarcs seeds
#puts "dropping cache ($err)"
foreach v {arcnos arcout arcids arcstart arcend growing \
arctags archeads allparents allchildren} {
global $v
catch {unset $v}
}
set allcwait 0
set nextarc 0
set cachedarcs 0
set seeds {}
getallcommits
}
proc writecache {f} {
global cachearc cachedarcs allccache
global arcstart arcend arcnos arcids arcout
set a $cachearc
set lim $cachedarcs
if {$lim - $a > 1000} {
set lim [expr {$a + 1000}]
}
if {[catch {
while {[incr a] <= $lim} {
if {[info exists arcend($a)]} {
puts $f [list $arcstart($a) $arcend($a) $arcids($a)]
} else {
puts $f [list $arcstart($a) {} $arcids($a)]
}
}
} err]} {
catch {close $f}
catch {file delete $allccache}
#puts "writing cache failed ($err)"
return 0
}
set cachearc [expr {$a - 1}]
if {$a > $cachedarcs} {
puts $f "1"
close $f
return 0
}
return 1
}
proc savecache {} {
global nextarc cachedarcs cachearc allccache
if {$nextarc == $cachedarcs} return
set cachearc 0
set cachedarcs $nextarc
catch {
set f [open $allccache w]
puts $f [list 1 $cachedarcs]
run writecache $f
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
# Returns 1 if a is an ancestor of b, -1 if b is an ancestor of a,
# or 0 if neither is true.
proc anc_or_desc {a b} {
global arcout arcstart arcend arcnos cached_isanc
if {$arcnos($a) eq $arcnos($b)} {
# Both are on the same arc(s); either both are the same BMP,
# or if one is not a BMP, the other is also not a BMP or is
# the BMP at end of the arc (and it only has 1 incoming arc).
gitk: Fix bug in the anc_or_desc routine I missed the case where both nodes have no children and therefore have no incoming arcs. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 13:57:04 +02:00
# Or both can be BMPs with no incoming arcs.
if {$a eq $b || $arcnos($a) eq {}} {
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
return 0
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
# assert {[llength $arcnos($a)] == 1}
set arc [lindex $arcnos($a) 0]
set i [lsearch -exact $arcids($arc) $a]
set j [lsearch -exact $arcids($arc) $b]
if {$i < 0 || $i > $j} {
return 1
} else {
return -1
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {![info exists arcout($a)]} {
set arc [lindex $arcnos($a) 0]
if {[info exists arcend($arc)]} {
set aend $arcend($arc)
} else {
set aend {}
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set a $arcstart($arc)
} else {
set aend $a
}
if {![info exists arcout($b)]} {
set arc [lindex $arcnos($b) 0]
if {[info exists arcend($arc)]} {
set bend $arcend($arc)
} else {
set bend {}
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set b $arcstart($arc)
} else {
set bend $b
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {$a eq $bend} {
return 1
}
if {$b eq $aend} {
return -1
}
if {[info exists cached_isanc($a,$bend)]} {
if {$cached_isanc($a,$bend)} {
return 1
}
}
if {[info exists cached_isanc($b,$aend)]} {
if {$cached_isanc($b,$aend)} {
return -1
}
if {[info exists cached_isanc($a,$bend)]} {
return 0
}
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set todo [list $a $b]
set anc($a) a
set anc($b) b
for {set i 0} {$i < [llength $todo]} {incr i} {
set x [lindex $todo $i]
if {$anc($x) eq {}} {
continue
}
foreach arc $arcnos($x) {
set xd $arcstart($arc)
if {$xd eq $bend} {
set cached_isanc($a,$bend) 1
set cached_isanc($b,$aend) 0
return 1
} elseif {$xd eq $aend} {
set cached_isanc($b,$aend) 1
set cached_isanc($a,$bend) 0
return -1
}
if {![info exists anc($xd)]} {
set anc($xd) $anc($x)
lappend todo $xd
} elseif {$anc($xd) ne $anc($x)} {
set anc($xd) {}
}
}
}
set cached_isanc($a,$bend) 0
set cached_isanc($b,$aend) 0
return 0
}
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
# This identifies whether $desc has an ancestor that is
# a growing tip of the graph and which is not an ancestor of $anc
# and returns 0 if so and 1 if not.
# If we subsequently discover a tag on such a growing tip, and that
# turns out to be a descendent of $anc (which it could, since we
# don't necessarily see children before parents), then $desc
# isn't a good choice to display as a descendent tag of
# $anc (since it is the descendent of another tag which is
# a descendent of $anc). Similarly, $anc isn't a good choice to
# display as a ancestor tag of $desc.
#
proc is_certain {desc anc} {
global arcnos arcout arcstart arcend growing problems
set certain {}
if {[llength $arcnos($anc)] == 1} {
# tags on the same arc are certain
if {$arcnos($desc) eq $arcnos($anc)} {
return 1
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {![info exists arcout($anc)]} {
# if $anc is partway along an arc, use the start of the arc instead
set a [lindex $arcnos($anc) 0]
set anc $arcstart($a)
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
}
if {[llength $arcnos($desc)] > 1 || [info exists arcout($desc)]} {
set x $desc
} else {
set a [lindex $arcnos($desc) 0]
set x $arcend($a)
}
if {$x == $anc} {
return 1
}
set anclist [list $x]
set dl($x) 1
set nnh 1
set ngrowanc 0
for {set i 0} {$i < [llength $anclist] && ($nnh > 0 || $ngrowanc > 0)} {incr i} {
set x [lindex $anclist $i]
if {$dl($x)} {
incr nnh -1
}
set done($x) 1
foreach a $arcout($x) {
if {[info exists growing($a)]} {
if {![info exists growanc($x)] && $dl($x)} {
set growanc($x) 1
incr ngrowanc
}
} else {
set y $arcend($a)
if {[info exists dl($y)]} {
if {$dl($y)} {
if {!$dl($x)} {
set dl($y) 0
if {![info exists done($y)]} {
incr nnh -1
}
if {[info exists growanc($x)]} {
incr ngrowanc -1
}
set xl [list $y]
for {set k 0} {$k < [llength $xl]} {incr k} {
set z [lindex $xl $k]
foreach c $arcout($z) {
if {[info exists arcend($c)]} {
set v $arcend($c)
if {[info exists dl($v)] && $dl($v)} {
set dl($v) 0
if {![info exists done($v)]} {
incr nnh -1
}
if {[info exists growanc($v)]} {
incr ngrowanc -1
}
lappend xl $v
}
}
}
}
}
}
} elseif {$y eq $anc || !$dl($x)} {
set dl($y) 0
lappend anclist $y
} else {
set dl($y) 1
lappend anclist $y
incr nnh
}
}
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
foreach x [array names growanc] {
if {$dl($x)} {
return 0
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
return 0
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
return 1
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
proc validate_arctags {a} {
global arctags idtags
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set i -1
set na $arctags($a)
foreach id $arctags($a) {
incr i
if {![info exists idtags($id)]} {
set na [lreplace $na $i $i]
incr i -1
}
}
set arctags($a) $na
}
proc validate_archeads {a} {
global archeads idheads
set i -1
set na $archeads($a)
foreach id $archeads($a) {
incr i
if {![info exists idheads($id)]} {
set na [lreplace $na $i $i]
incr i -1
}
}
set archeads($a) $na
}
# Return the list of IDs that have tags that are descendents of id,
# ignoring IDs that are descendents of IDs already reported.
proc desctags {id} {
global arcnos arcstart arcids arctags idtags allparents
global growing cached_dtags
if {![info exists allparents($id)]} {
return {}
}
set t1 [clock clicks -milliseconds]
set argid $id
if {[llength $arcnos($id)] == 1 && [llength $allparents($id)] == 1} {
# part-way along an arc; check that arc first
set a [lindex $arcnos($id) 0]
if {$arctags($a) ne {}} {
validate_arctags $a
set i [lsearch -exact $arcids($a) $id]
set tid {}
foreach t $arctags($a) {
set j [lsearch -exact $arcids($a) $t]
if {$j >= $i} break
set tid $t
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {$tid ne {}} {
return $tid
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set id $arcstart($a)
if {[info exists idtags($id)]} {
return $id
}
}
if {[info exists cached_dtags($id)]} {
return $cached_dtags($id)
}
set origid $id
set todo [list $id]
set queued($id) 1
set nc 1
for {set i 0} {$i < [llength $todo] && $nc > 0} {incr i} {
set id [lindex $todo $i]
set done($id) 1
set ta [info exists hastaggedancestor($id)]
if {!$ta} {
incr nc -1
}
# ignore tags on starting node
if {!$ta && $i > 0} {
if {[info exists idtags($id)]} {
set tagloc($id) $id
set ta 1
} elseif {[info exists cached_dtags($id)]} {
set tagloc($id) $cached_dtags($id)
set ta 1
}
}
foreach a $arcnos($id) {
set d $arcstart($a)
if {!$ta && $arctags($a) ne {}} {
validate_arctags $a
if {$arctags($a) ne {}} {
lappend tagloc($id) [lindex $arctags($a) end]
}
}
if {$ta || $arctags($a) ne {}} {
set tomark [list $d]
for {set j 0} {$j < [llength $tomark]} {incr j} {
set dd [lindex $tomark $j]
if {![info exists hastaggedancestor($dd)]} {
if {[info exists done($dd)]} {
foreach b $arcnos($dd) {
lappend tomark $arcstart($b)
}
if {[info exists tagloc($dd)]} {
unset tagloc($dd)
}
} elseif {[info exists queued($dd)]} {
incr nc -1
}
set hastaggedancestor($dd) 1
}
}
}
if {![info exists queued($d)]} {
lappend todo $d
set queued($d) 1
if {![info exists hastaggedancestor($d)]} {
incr nc
}
}
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
}
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set tags {}
foreach id [array names tagloc] {
if {![info exists hastaggedancestor($id)]} {
foreach t $tagloc($id) {
if {[lsearch -exact $tags $t] < 0} {
lappend tags $t
}
}
}
}
set t2 [clock clicks -milliseconds]
set loopix $i
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
# remove tags that are descendents of other tags
for {set i 0} {$i < [llength $tags]} {incr i} {
set a [lindex $tags $i]
for {set j 0} {$j < $i} {incr j} {
set b [lindex $tags $j]
set r [anc_or_desc $a $b]
if {$r == 1} {
set tags [lreplace $tags $j $j]
incr j -1
incr i -1
} elseif {$r == -1} {
set tags [lreplace $tags $i $i]
incr i -1
break
gitk: Update preceding/following tag info when creating a tag Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-08 12:55:36 +02:00
}
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {[array names growing] ne {}} {
# graph isn't finished, need to check if any tag could get
# eclipsed by another tag coming later. Simply ignore any
# tags that could later get eclipsed.
set ctags {}
foreach t $tags {
if {[is_certain $t $origid]} {
lappend ctags $t
}
gitk: Update preceding/following tag info when creating a tag Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-08 12:55:36 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {$tags eq $ctags} {
set cached_dtags($origid) $tags
} else {
set tags $ctags
gitk: Update preceding/following tag info when creating a tag Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-08 12:55:36 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
} else {
set cached_dtags($origid) $tags
}
set t3 [clock clicks -milliseconds]
if {0 && $t3 - $t1 >= 100} {
puts "iterating descendents ($loopix/[llength $todo] nodes) took\
[expr {$t2-$t1}]+[expr {$t3-$t2}]ms, $nc candidates left"
gitk: Update preceding/following tag info when creating a tag Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-08 12:55:36 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
return $tags
}
gitk: Update preceding/following tag info when creating a tag Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-08 12:55:36 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
proc anctags {id} {
global arcnos arcids arcout arcend arctags idtags allparents
global growing cached_atags
if {![info exists allparents($id)]} {
return {}
}
set t1 [clock clicks -milliseconds]
set argid $id
if {[llength $arcnos($id)] == 1 && [llength $allparents($id)] == 1} {
# part-way along an arc; check that arc first
set a [lindex $arcnos($id) 0]
if {$arctags($a) ne {}} {
validate_arctags $a
set i [lsearch -exact $arcids($a) $id]
foreach t $arctags($a) {
set j [lsearch -exact $arcids($a) $t]
if {$j > $i} {
return $t
}
}
gitk: Update preceding/following tag info when creating a tag Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-08 12:55:36 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {![info exists arcend($a)]} {
return {}
}
set id $arcend($a)
if {[info exists idtags($id)]} {
return $id
}
}
if {[info exists cached_atags($id)]} {
return $cached_atags($id)
}
set origid $id
set todo [list $id]
set queued($id) 1
set taglist {}
set nc 1
for {set i 0} {$i < [llength $todo] && $nc > 0} {incr i} {
set id [lindex $todo $i]
set done($id) 1
set td [info exists hastaggeddescendent($id)]
if {!$td} {
incr nc -1
}
# ignore tags on starting node
if {!$td && $i > 0} {
if {[info exists idtags($id)]} {
set tagloc($id) $id
set td 1
} elseif {[info exists cached_atags($id)]} {
set tagloc($id) $cached_atags($id)
set td 1
}
}
foreach a $arcout($id) {
if {!$td && $arctags($a) ne {}} {
validate_arctags $a
if {$arctags($a) ne {}} {
lappend tagloc($id) [lindex $arctags($a) 0]
}
}
if {![info exists arcend($a)]} continue
set d $arcend($a)
if {$td || $arctags($a) ne {}} {
set tomark [list $d]
for {set j 0} {$j < [llength $tomark]} {incr j} {
set dd [lindex $tomark $j]
if {![info exists hastaggeddescendent($dd)]} {
if {[info exists done($dd)]} {
foreach b $arcout($dd) {
if {[info exists arcend($b)]} {
lappend tomark $arcend($b)
}
}
if {[info exists tagloc($dd)]} {
unset tagloc($dd)
}
} elseif {[info exists queued($dd)]} {
incr nc -1
}
set hastaggeddescendent($dd) 1
}
}
}
if {![info exists queued($d)]} {
lappend todo $d
set queued($d) 1
if {![info exists hastaggeddescendent($d)]} {
incr nc
}
}
}
}
set t2 [clock clicks -milliseconds]
set loopix $i
set tags {}
foreach id [array names tagloc] {
if {![info exists hastaggeddescendent($id)]} {
foreach t $tagloc($id) {
if {[lsearch -exact $tags $t] < 0} {
lappend tags $t
}
}
gitk: Update preceding/following tag info when creating a tag Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-08 12:55:36 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
# remove tags that are ancestors of other tags
for {set i 0} {$i < [llength $tags]} {incr i} {
set a [lindex $tags $i]
for {set j 0} {$j < $i} {incr j} {
set b [lindex $tags $j]
set r [anc_or_desc $a $b]
if {$r == -1} {
set tags [lreplace $tags $j $j]
incr j -1
incr i -1
} elseif {$r == 1} {
set tags [lreplace $tags $i $i]
incr i -1
break
}
}
}
if {[array names growing] ne {}} {
# graph isn't finished, need to check if any tag could get
# eclipsed by another tag coming later. Simply ignore any
# tags that could later get eclipsed.
set ctags {}
foreach t $tags {
if {[is_certain $origid $t]} {
lappend ctags $t
}
}
if {$tags eq $ctags} {
set cached_atags($origid) $tags
} else {
set tags $ctags
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
} else {
set cached_atags($origid) $tags
}
set t3 [clock clicks -milliseconds]
if {0 && $t3 - $t1 >= 100} {
puts "iterating ancestors ($loopix/[llength $todo] nodes) took\
[expr {$t2-$t1}]+[expr {$t3-$t2}]ms, $nc candidates left"
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
return $tags
gitk: Add a row context-menu item for creating a new branch Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:41:04 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
# Return the list of IDs that have heads that are descendents of id,
# including id itself if it has a head.
proc descheads {id} {
global arcnos arcstart arcids archeads idheads cached_dheads
global allparents
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {![info exists allparents($id)]} {
return {}
}
gitk: Fix bug causing nearby tags/heads to sometimes not be displayed When we compute descendent heads and descendent/ancestor tags, we cache the results. We need to be careful to invalidate the cache when we add stuff to the graph. Also make sure that when we cache descendent heads for a node we only cache the heads that are actually descendents of that node. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-18 14:39:21 +02:00
set aret {}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {[llength $arcnos($id)] == 1 && [llength $allparents($id)] == 1} {
# part-way along an arc; check it first
set a [lindex $arcnos($id) 0]
if {$archeads($a) ne {}} {
validate_archeads $a
set i [lsearch -exact $arcids($a) $id]
foreach t $archeads($a) {
set j [lsearch -exact $arcids($a) $t]
if {$j > $i} break
gitk: Fix bug causing nearby tags/heads to sometimes not be displayed When we compute descendent heads and descendent/ancestor tags, we cache the results. We need to be careful to invalidate the cache when we add stuff to the graph. Also make sure that when we cache descendent heads for a node we only cache the heads that are actually descendents of that node. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-18 14:39:21 +02:00
lappend aret $t
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
}
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set id $arcstart($a)
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set origid $id
set todo [list $id]
set seen($id) 1
gitk: Fix bug causing nearby tags/heads to sometimes not be displayed When we compute descendent heads and descendent/ancestor tags, we cache the results. We need to be careful to invalidate the cache when we add stuff to the graph. Also make sure that when we cache descendent heads for a node we only cache the heads that are actually descendents of that node. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-18 14:39:21 +02:00
set ret {}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
for {set i 0} {$i < [llength $todo]} {incr i} {
set id [lindex $todo $i]
if {[info exists cached_dheads($id)]} {
set ret [concat $ret $cached_dheads($id)]
} else {
if {[info exists idheads($id)]} {
lappend ret $id
}
foreach a $arcnos($id) {
if {$archeads($a) ne {}} {
gitk: Add a progress bar to show progress while resetting Since git reset now gets chatty while resetting, we were getting errors reported when a reset was done using the "reset branch to here" menu item. With this we now read the progress messages from git reset and update a progress bar. Because git reset outputs the progress messages to standard error, and Tcl treats messages to standard error as error messages, we have to invoke git reset via a shell and redirect standard error into standard output. This also fixes a bug in computing descendent heads when head ids are changed via a reset. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-26 03:09:49 +02:00
validate_archeads $a
if {$archeads($a) ne {}} {
set ret [concat $ret $archeads($a)]
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
}
set d $arcstart($a)
if {![info exists seen($d)]} {
lappend todo $d
set seen($d) 1
}
}
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
set ret [lsort -unique $ret]
set cached_dheads($origid) $ret
gitk: Fix bug causing nearby tags/heads to sometimes not be displayed When we compute descendent heads and descendent/ancestor tags, we cache the results. We need to be careful to invalidate the cache when we add stuff to the graph. Also make sure that when we cache descendent heads for a node we only cache the heads that are actually descendents of that node. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-18 14:39:21 +02:00
return [concat $ret $aret]
gitk: Add a context menu for heads This menu allows you to check out a branch and to delete a branch. If you ask to delete a branch that has commits that aren't on any other branch, gitk will prompt for confirmation before doing the deletion. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:52:01 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
proc addedtag {id} {
global arcnos arcout cached_dtags cached_atags
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {![info exists arcnos($id)]} return
if {![info exists arcout($id)]} {
recalcarc [lindex $arcnos($id) 0]
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
catch {unset cached_dtags}
catch {unset cached_atags}
gitk: Add a menu item for cherry-picking commits This does a git-cherry-pick -r to cherry-pick the commit that was right-clicked on to the head of the current branch. This would work better with some minor changes to the git-cherry-pick script. Along the way, this changes desc_heads to record the names of the descendent heads rather than their IDs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-06 13:08:05 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
proc addedhead {hid head} {
global arcnos arcout cached_dheads
if {![info exists arcnos($hid)]} return
if {![info exists arcout($hid)]} {
recalcarc [lindex $arcnos($hid) 0]
}
catch {unset cached_dheads}
}
proc removedhead {hid head} {
global cached_dheads
catch {unset cached_dheads}
}
proc movedhead {hid head} {
global arcnos arcout cached_dheads
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
if {![info exists arcnos($hid)]} return
if {![info exists arcout($hid)]} {
recalcarc [lindex $arcnos($hid) 0]
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
catch {unset cached_dheads}
}
proc changedrefs {} {
global cached_dheads cached_dtags cached_atags
global arctags archeads arcnos arcout idheads idtags
foreach id [concat [array names idheads] [array names idtags]] {
if {[info exists arcnos($id)] && ![info exists arcout($id)]} {
set a [lindex $arcnos($id) 0]
if {![info exists donearc($a)]} {
recalcarc $a
set donearc($a) 1
}
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
}
gitk: New infrastructure for working out branches & previous/next tags Instead of working out descendent heads and descendent & ancestor branches in a two-pass algorithm, this reads and stores a simplified version of the graph topology, and works out descendent/ancestor tags and descendent heads on demand (with a bit of caching). The advantages of this are, first, that we now don't have to use --topo-order on the git rev-list process. Secondly, we don't have to re-read the whole graph when tags or heads change or even when the graph changes. Since we can cope with parents coming before children, we can update the graph by running a git rev-list with arguments that just give us the new commits, and merge the new commits into the simplified graph. The graph is simplified in the sense that commits with exactly one parent and one child (which is >90% of them in most cases) are grouped together into arcs joining nodes or 'branch/merge points', which are the commits that don't have exactly 1 parent and 1 child. This reduces the size of the graph substantially and decreases the time to traverse it correspondingly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 12:29:25 +02:00
catch {unset cached_dtags}
catch {unset cached_atags}
catch {unset cached_dheads}
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
}
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
proc rereadrefs {} {
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
global idtags idheads idotherrefs mainheadid
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
set refids [concat [array names idtags] \
[array names idheads] [array names idotherrefs]]
foreach id $refids {
if {![info exists ref($id)]} {
set ref($id) [listrefs $id]
}
}
gitk: Fix another collection of bugs * Fixed a bug that occasionally resulted in Tcl "can't use empty string as argument to incr" errors - rowofcommit was sometimes not calling update_arcrows when it needed to. * Fixed a "no such element in array" error when removing a fake row, by unsetting currentid and selectedline in removerow if the row we are removing is the currently selected row. * Made the "update commits" function always do "reread references". * Made dodiffindex et al. remove the fake row(s) if necessary. * Fixed a bug where clicking on a row in the graph display pane didn't account for horizontal scrolling of the pane. * Started changing things that cached information based on row numbers to use commit IDs instead -- this converts the "select line" items that are put into the history list to use "select by ID" instead. * Simplified redrawtags a bit, and fixed a bug where it would use the mainfont for working out how far it extends to the right in the graph display pane rather than the actual font (which might be bold). * Fixed a bug where "reread references" wouldn't notice if the currently checked-out head had changed. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-26 13:03:43 +01:00
set oldmainhead $mainheadid
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
readrefs
gitk: Recompute ancestor/descendent heads/tags when rereading refs We weren't updating the desc_heads, desc_tags and anc_tags arrays when rereading the set of heads/tags/etc. The tricky thing to get right here is restarting the computation correctly when we are only half-way through it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-08-02 01:38:10 +02:00
changedrefs
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
set refids [lsort -unique [concat $refids [array names idtags] \
[array names idheads] [array names idotherrefs]]]
foreach id $refids {
set v [listrefs $id]
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
if {![info exists ref($id)] || $ref($id) != $v} {
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
redrawtags $id
}
}
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
if {$oldmainhead ne $mainheadid} {
redrawtags $oldmainhead
redrawtags $mainheadid
}
gitk: Add a window to list branches, tags and other references This adds an entry to the File menu labelled "List references" which pops up a window showing a sorted list of branches, tags, and other references, with a little icon beside each to indicate what sort it is. The list only shows refs that point to a commit that is included in the graph, and if you click on a ref, the corresponding commit is selected in the main window. The list of refs gets updated dynamically. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-20 11:36:20 +02:00
run refill_reflist
Added re-read refs command, and display all refs. These are features requested by Junio. Any plain file under .git/refs whose contents start with 40 hex characters is taken as a reference and displayed like a head but with a light blue background (unless it is in .git/refs/tags or .git/refs/heads, in which case it is displayed as before). There is now a "Reread references" menu item in the File menu which re-reads all the plain files under .git/refs and redisplays any references that have changed.
2005-08-19 14:14:28 +02:00
}
[PATCH] gitk: rereadrefs needs listrefs The listrefs procedure was inadvertently removed during the course of development, but there is still a user of it, so resurrect it. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-11 18:50:47 +02:00
proc listrefs {id} {
global idtags idheads idotherrefs
set x {}
if {[info exists idtags($id)]} {
set x $idtags($id)
}
set y {}
if {[info exists idheads($id)]} {
set y $idheads($id)
}
set z {}
if {[info exists idotherrefs($id)]} {
set z $idotherrefs($id)
}
return [list $x $y $z]
}
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
proc showtag {tag isnew} {
gitk: Speed up the reading of references We were doing two execs for each tag - one to map the tag ID to a commit ID and one to read the contents of the tag for later display. This speeds up the process by not reading the contents of the tag (instead it is read later if needed), and by using the -d flag to git show-ref, which gives us refs/tags/foo^{} lines which give us the commit ID. Also this uses string operations instead of regexps. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-11 02:36:53 +02:00
global ctext tagcontents tagids linknum tagobjid
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
if {$isnew} {
addtohistory [list showtag $tag 0]
}
$ctext conf -state normal
gitk: First cut at a search function in the patch/file display window This does incremental highlighting of matches to the search string but doesn't do true incremental search a la emacs. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 02:16:03 +02:00
clear_ctext
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
settabs 0
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
set linknum 0
gitk: Speed up the reading of references We were doing two execs for each tag - one to map the tag ID to a commit ID and one to read the contents of the tag for later display. This speeds up the process by not reading the contents of the tag (instead it is read later if needed), and by using the -d flag to git show-ref, which gives us refs/tags/foo^{} lines which give us the commit ID. Also this uses string operations instead of regexps. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-11 02:36:53 +02:00
if {![info exists tagcontents($tag)]} {
catch {
set tagcontents($tag) [exec git cat-file tag $tagobjid($tag)]
}
}
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
if {[info exists tagcontents($tag)]} {
set text $tagcontents($tag)
} else {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
set text "[mc "Tag"]: $tag\n[mc "Id"]: $tagids($tag)"
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
}
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
appendwithlinks $text {}
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
$ctext conf -state disabled
gitk: Use a text widget for the file list This lets us do things like highlighting all the entries for which the corresponding part of the diff is at least partly visible in the commit/patch display window, and in future it will let us display the file list in a hierarchical form rather than as a flat file list. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-27 11:21:49 +02:00
init_flist {}
Display the contents of a tag when the user clicks on it. This just displays the result of git-cat-file on the tag in the details pane. If the tag is a "direct" tag (the tag file contains the SHA1 ID of a commit rather than a tag), we show the tag name and SHA1 ID.
2005-08-19 15:11:39 +02:00
}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
proc doquit {} {
global stopped
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
global gitktmpdir
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
set stopped 100
Make gitk save and restore the user set window position. gitk was saving widget sizes and positions when the main window was destroyed, which is after all child widgets are destroyed. The cure is to trap the WM_DELETE_WINDOW event before the gui is torn down. Also, the saved geometry was captured using "winfo geometry .", rather than "wm geometry ." Under Linux, these two return different answers and the latter one is correct. [jc: credit goes to Brett Schwarz for suggesting the use of "wm protocol"; I also squashed the follow-up patch to remove extraneous -0 from expressions.] Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-09 04:22:24 +01:00
savestuff .
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
destroy .
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
if {[info exists gitktmpdir]} {
catch {file delete -force $gitktmpdir}
}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
}
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
proc mkfontdisp {font top which} {
global fontattr fontpref $font
set fontpref($font) [set $font]
button $top.${font}but -text $which -font optionfont \
-command [list choosefont $font $which]
label $top.$font -relief flat -font $font \
-text $fontattr($font,family) -justify left
grid x $top.${font}but $top.$font -sticky w
}
proc choosefont {font which} {
global fontparam fontlist fonttop fontattr
gitk: Make gitk dialog windows transient Transient windows are always kept above their parent, and don't occupy any space in the taskbar, which is useful for dialogs. Also, when transient is used, it is important to bind windows to the correct parent. This commit adds transient annotations to all dialogs, ensures usage of the correct parent for error and confirmation popups, and, as a side job, makes gitk preserve the create tag dialog window in case of errors. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:45 +01:00
global prefstop
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
set fontparam(which) $which
set fontparam(font) $font
set fontparam(family) [font actual $font -family]
set fontparam(size) $fontattr($font,size)
set fontparam(weight) $fontattr($font,weight)
set fontparam(slant) $fontattr($font,slant)
set top .gitkfont
set fonttop $top
if {![winfo exists $top]} {
font create sample
eval font config sample [font actual $font]
toplevel $top
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $top $prefstop
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
wm title $top [mc "Gitk font chooser"]
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
label $top.l -textvariable fontparam(which)
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
pack $top.l -side top
set fontlist [lsort [font families]]
frame $top.f
listbox $top.f.fam -listvariable fontlist \
-yscrollcommand [list $top.f.sb set]
bind $top.f.fam <<ListboxSelect>> selfontfam
scrollbar $top.f.sb -command [list $top.f.fam yview]
pack $top.f.sb -side right -fill y
pack $top.f.fam -side left -fill both -expand 1
pack $top.f -side top -fill both -expand 1
frame $top.g
spinbox $top.g.size -from 4 -to 40 -width 4 \
-textvariable fontparam(size) \
-validatecommand {string is integer -strict %s}
checkbutton $top.g.bold -padx 5 \
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
-font {{Times New Roman} 12 bold} -text [mc "B"] -indicatoron 0 \
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
-variable fontparam(weight) -onvalue bold -offvalue normal
checkbutton $top.g.ital -padx 5 \
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
-font {{Times New Roman} 12 italic} -text [mc "I"] -indicatoron 0 \
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
-variable fontparam(slant) -onvalue italic -offvalue roman
pack $top.g.size $top.g.bold $top.g.ital -side left
pack $top.g -side top
canvas $top.c -width 150 -height 50 -border 2 -relief sunk \
-background white
$top.c create text 100 25 -anchor center -text $which -font sample \
-fill black -tags text
bind $top.c <Configure> [list centertext $top.c]
pack $top.c -side top -fill x
frame $top.buts
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
button $top.buts.ok -text [mc "OK"] -command fontok -default active
button $top.buts.can -text [mc "Cancel"] -command fontcan -default normal
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Key-Return> fontok
bind $top <Key-Escape> fontcan
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
grid $top.buts.ok $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
pack $top.buts -side bottom -fill x
trace add variable fontparam write chg_fontparam
} else {
raise $top
$top.c itemconf text -text $which
}
set i [lsearch -exact $fontlist $fontparam(family)]
if {$i >= 0} {
$top.f.fam selection set $i
$top.f.fam see $i
}
}
proc centertext {w} {
$w coords text [expr {[winfo width $w] / 2}] [expr {[winfo height $w] / 2}]
}
proc fontok {} {
global fontparam fontpref prefstop
set f $fontparam(font)
set fontpref($f) [list $fontparam(family) $fontparam(size)]
if {$fontparam(weight) eq "bold"} {
lappend fontpref($f) "bold"
}
if {$fontparam(slant) eq "italic"} {
lappend fontpref($f) "italic"
}
set w $prefstop.$f
$w conf -text $fontparam(family) -font $fontpref($f)
fontcan
}
proc fontcan {} {
global fonttop fontparam
if {[info exists fonttop]} {
catch {destroy $fonttop}
catch {font delete sample}
unset fonttop
unset fontparam
}
}
proc selfontfam {} {
global fonttop fontparam
set i [$fonttop.f.fam curselection]
if {$i ne {}} {
set fontparam(family) [$fonttop.f.fam get $i]
}
}
proc chg_fontparam {v sub op} {
global fontparam
font config sample -$sub $fontparam($sub)
}
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
proc doprefs {} {
gitk: Get rid of the diffopts variable The only thing that could be specified with diffopts was the number of lines of context, but there is already a spinbox for that. So this gets rid of it. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:22:00 +02:00
global maxwidth maxgraphpct
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
global oldprefs prefstop showneartags showlocalchanges
gitk: Make the background color of marked lines configurable This makes it possible for the user to configure the background color of lines that are "marked". At the moment only the "show the origin of this line" function marks lines. This also makes the user's choice persistent by saving it in ~/.gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 12:37:21 +01:00
global bgcolor fgcolor ctext diffcolors selectbgcolor markbgcolor
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
global tabstop limitdiffs autoselect extdifftool perfile_attrs
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
global hideremotes
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
set top .gitkprefs
set prefstop $top
if {[winfo exists $top]} {
raise $top
return
gitk: Disable fastdate stuff for now It has a fatal flaw in that it only handles timezones that are a multiple of an hour. It's really only needed with Tk8.5, where the clock format command has been reimplemented in Tcl and is much slower than in Tk8.4. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-20 23:56:07 +01:00
}
Merge branch 'master' into dev
2007-10-23 14:40:50 +02:00
foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
limitdiffs tabstop perfile_attrs hideremotes} {
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
set oldprefs($v) [set $v]
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
}
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
toplevel $top
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
wm title $top [mc "Gitk preferences"]
gitk: Fix transient windows on Win32 and MacOS Transient windows cause problems on these platforms: - On Win32 the windows appear in the top left corner of the screen. In order to fix it, this patch causes them to be explicitly centered on their parents by an idle handler. - On MacOS with Tk 8.4 they appear without a title bar. Since it is clearly unacceptable, this patch disables transient on that platform. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-11 21:55:42 +01:00
make_transient $top .
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.ldisp -text [mc "Commit list display options"]
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
grid $top.ldisp - -sticky w -pady 10
label $top.spacer -text " "
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.maxwidthl -text [mc "Maximum graph width (lines)"] \
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
-font optionfont
spinbox $top.maxwidth -from 0 -to 100 -width 4 -textvariable maxwidth
grid $top.spacer $top.maxwidthl $top.maxwidth -sticky w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.maxpctl -text [mc "Maximum graph width (% of pane)"] \
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
-font optionfont
spinbox $top.maxpct -from 1 -to 100 -width 4 -textvariable maxgraphpct
grid x $top.maxpctl $top.maxpct -sticky w
gitk: Use check-buttons' -text property instead of separate labels Previously the check-buttons' labels in the Preferences were separate widgets. This had the disadvantage that in order to toggle the check-button with the mouse the check-box had to be clicked. With this change the check-box can also be toggled by clicking the label. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-02 21:42:16 +01:00
checkbutton $top.showlocal -text [mc "Show local changes"] \
-font optionfont -variable showlocalchanges
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
grid x $top.showlocal -sticky w
gitk: Use check-buttons' -text property instead of separate labels Previously the check-buttons' labels in the Preferences were separate widgets. This had the disadvantage that in order to toggle the check-button with the mouse the check-box had to be clicked. With this change the check-box can also be toggled by clicking the label. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-02 21:42:16 +01:00
checkbutton $top.autoselect -text [mc "Auto-select SHA1"] \
-font optionfont -variable autoselect
[PATCH] gitk: make autoselect optional Whenever a commit is selected in the graph pane, its SHA1 is automatically put into the selection buffer for cut and paste. However, some users may find this behavior annoying since it can overwrite something they actually wanted to keep in the buffer. This makes the behavior optional under the name "Auto-select SHA1", but continues to default to "on". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-06 12:49:25 +01:00
grid x $top.autoselect -sticky w
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.ddisp -text [mc "Diff display options"]
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
grid $top.ddisp - -sticky w -pady 10
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.tabstopl -text [mc "Tab spacing"] -font optionfont
gitk: Ensure tabstop setting gets restored by Cancel button We weren't restoring the tabstop setting if the user pressed the Cancel button in the Edit/Preferences window. Also improved the label for the checkbox (made it "Tab spacing" rather than the laconic "tabstop") and moved it above the "Display nearby tags" checkbox. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:33:38 +02:00
spinbox $top.tabstop -from 1 -to 20 -width 4 -textvariable tabstop
grid x $top.tabstopl $top.tabstop -sticky w
gitk: Use check-buttons' -text property instead of separate labels Previously the check-buttons' labels in the Preferences were separate widgets. This had the disadvantage that in order to toggle the check-button with the mouse the check-box had to be clicked. With this change the check-box can also be toggled by clicking the label. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-02 21:42:16 +01:00
checkbutton $top.ntag -text [mc "Display nearby tags"] \
-font optionfont -variable showneartags
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
grid x $top.ntag -sticky w
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
checkbutton $top.hideremotes -text [mc "Hide remote refs"] \
-font optionfont -variable hideremotes
grid x $top.hideremotes -sticky w
gitk: Use check-buttons' -text property instead of separate labels Previously the check-buttons' labels in the Preferences were separate widgets. This had the disadvantage that in order to toggle the check-button with the mouse the check-box had to be clicked. With this change the check-box can also be toggled by clicking the label. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-02 21:42:16 +01:00
checkbutton $top.ldiff -text [mc "Limit diffs to listed paths"] \
-font optionfont -variable limitdiffs
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
grid x $top.ldiff -sticky w
gitk: Use check-buttons' -text property instead of separate labels Previously the check-buttons' labels in the Preferences were separate widgets. This had the disadvantage that in order to toggle the check-button with the mouse the check-box had to be clicked. With this change the check-box can also be toggled by clicking the label. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-02 21:42:16 +01:00
checkbutton $top.lattr -text [mc "Support per-file encodings"] \
-font optionfont -variable perfile_attrs
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
grid x $top.lattr -sticky w
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
entry $top.extdifft -textvariable extdifftool
frame $top.extdifff
label $top.extdifff.l -text [mc "External diff tool" ] -font optionfont \
-padx 10
button $top.extdifff.b -text [mc "Choose..."] -font optionfont \
-command choose_extdiff
pack $top.extdifff.l $top.extdifff.b -side left
grid x $top.extdifff $top.extdifft -sticky w
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.cdisp -text [mc "Colors: press to choose"]
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
grid $top.cdisp - -sticky w -pady 10
label $top.bg -padx 40 -relief sunk -background $bgcolor
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.bgbut -text [mc "Background"] -font optionfont \
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 20:48:30 +01:00
-command [list choosecolor bgcolor {} $top.bg [mc "background"] setbg]
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
grid x $top.bgbut $top.bg -sticky w
label $top.fg -padx 40 -relief sunk -background $fgcolor
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.fgbut -text [mc "Foreground"] -font optionfont \
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 20:48:30 +01:00
-command [list choosecolor fgcolor {} $top.fg [mc "foreground"] setfg]
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
grid x $top.fgbut $top.fg -sticky w
label $top.diffold -padx 40 -relief sunk -background [lindex $diffcolors 0]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.diffoldbut -text [mc "Diff: old lines"] -font optionfont \
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 20:48:30 +01:00
-command [list choosecolor diffcolors 0 $top.diffold [mc "diff old lines"] \
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
[list $ctext tag conf d0 -foreground]]
grid x $top.diffoldbut $top.diffold -sticky w
label $top.diffnew -padx 40 -relief sunk -background [lindex $diffcolors 1]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.diffnewbut -text [mc "Diff: new lines"] -font optionfont \
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 20:48:30 +01:00
-command [list choosecolor diffcolors 1 $top.diffnew [mc "diff new lines"] \
gitk: Unify handling of merge diffs with normal 2-way diffs This adds code to getblobdiffline to make it able to recognize and display merge diffs (i.e. N-way diffs for N >= 3) as well as normal two-way diffs. This means that it can also correctly display the 3-way diff of the local changes when the git repository is in the middle of a merge with conflicts. This also removes getmergediffline and changes mergediff to invoke getblobdiffline rather than getmergediffline. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 12:34:47 +01:00
[list $ctext tag conf dresult -foreground]]
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
grid x $top.diffnewbut $top.diffnew -sticky w
label $top.hunksep -padx 40 -relief sunk -background [lindex $diffcolors 2]
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.hunksepbut -text [mc "Diff: hunk header"] -font optionfont \
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
-command [list choosecolor diffcolors 2 $top.hunksep \
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 20:48:30 +01:00
[mc "diff hunk header"] \
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
[list $ctext tag conf hunksep -foreground]]
grid x $top.hunksepbut $top.hunksep -sticky w
gitk: Make the background color of marked lines configurable This makes it possible for the user to configure the background color of lines that are "marked". At the moment only the "show the origin of this line" function marks lines. This also makes the user's choice persistent by saving it in ~/.gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 12:37:21 +01:00
label $top.markbgsep -padx 40 -relief sunk -background $markbgcolor
button $top.markbgbut -text [mc "Marked line bg"] -font optionfont \
-command [list choosecolor markbgcolor {} $top.markbgsep \
[mc "marked line background"] \
[list $ctext tag conf omark -background]]
grid x $top.markbgbut $top.markbgsep -sticky w
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
label $top.selbgsep -padx 40 -relief sunk -background $selectbgcolor
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.selbgbut -text [mc "Select bg"] -font optionfont \
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-06 20:48:30 +01:00
-command [list choosecolor selectbgcolor {} $top.selbgsep [mc "background"] setselbg]
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
grid x $top.selbgbut $top.selbgsep -sticky w
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
label $top.cfont -text [mc "Fonts: press to choose"]
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
grid $top.cfont - -sticky w -pady 10
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
mkfontdisp mainfont $top [mc "Main font"]
mkfontdisp textfont $top [mc "Diff display font"]
mkfontdisp uifont $top [mc "User interface font"]
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
frame $top.buts
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
button $top.buts.ok -text [mc "OK"] -command prefsok -default active
button $top.buts.can -text [mc "Cancel"] -command prefscan -default normal
gitk: Add Return and Escape bindings to dialogs It is often more convenient to dismiss or accept a dialog using the keyboard, than by clicking buttons on the screen. This commit adds key binding to make it possible with gitk's dialogs. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-02 19:59:44 +01:00
bind $top <Key-Return> prefsok
bind $top <Key-Escape> prefscan
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
grid $top.buts.ok $top.buts.can
grid columnconfigure $top.buts 0 -weight 1 -uniform a
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - - -pady 10 -sticky ew
[PATCH] Improve look-and-feel of the gitk tool. Made the default buttons on the dialog active and focused upon the dialog appearence. Bound 'Escape' and 'Return' keys to the dialog dismissal where it was appropriate: mainly for dialogs with only one button and no editable fields. Unified the look of the "About gitk" and "Key bindings" dialogs. Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-03-27 12:36:59 +02:00
bind $top <Visibility> "focus $top.buts.ok"
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
}
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
proc choose_extdiff {} {
global extdifftool
gitk: Mark some more strings for translation Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-30 21:17:25 +02:00
set prog [tk_getOpenFile -title [mc "External diff tool"] -multiple false]
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
if {$prog ne {}} {
set extdifftool $prog
}
}
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
proc choosecolor {v vi w x cmd} {
global $v
set c [tk_chooseColor -initialcolor [lindex [set $v] $vi] \
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
-title [mc "Gitk: choose color for %s" $x]]
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
if {$c eq {}} return
$w conf -background $c
lset $v $vi $c
eval $cmd $c
}
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
proc setselbg {c} {
global bglist cflist
foreach w $bglist {
$w configure -selectbackground $c
}
$cflist tag configure highlight \
-background [$cflist cget -selectbackground]
allcanvs itemconf secsel -fill $c
}
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
proc setbg {c} {
global bglist
foreach w $bglist {
$w conf -background $c
}
}
proc setfg {c} {
global fglist canv
foreach w $fglist {
$w conf -foreground $c
}
allcanvs itemconf text -fill $c
$canv itemconf circle -outline $c
gitk: Add a way to mark a commit, plus a "find descendant" command This adds a context-menu command to put a mark on this commit. There is at most one marked commit at any time, and it is indicated by a box drawn around the headline. Once a commit is marked, two other context-menu commands become available: one to select the marked commit, and another to find the closest common descendant of this commit and the marked commit. The "find common descendant" command uses the displayed parent/child relationships (i.e. the rewritten parent pointers produced by git log), not the real parent/child relationships. Currently the UI will be unresponsive while gitk is working out the nearest common descendant; this should be improved in future. Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-09 01:34:46 +02:00
$canv itemconf markid -outline $c
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
}
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
proc prefscan {} {
gitk: Ensure tabstop setting gets restored by Cancel button We weren't restoring the tabstop setting if the user pressed the Cancel button in the Edit/Preferences window. Also improved the label for the checkbox (made it "Tab spacing" rather than the laconic "tabstop") and moved it above the "Display nearby tags" checkbox. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:33:38 +02:00
global oldprefs prefstop
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
Merge branch 'master' into dev
2007-10-23 14:40:50 +02:00
foreach v {maxwidth maxgraphpct showneartags showlocalchanges \
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
limitdiffs tabstop perfile_attrs hideremotes} {
gitk: Ensure tabstop setting gets restored by Cancel button We weren't restoring the tabstop setting if the user pressed the Cancel button in the Edit/Preferences window. Also improved the label for the checkbox (made it "Tab spacing" rather than the laconic "tabstop") and moved it above the "Display nearby tags" checkbox. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:33:38 +02:00
global $v
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
set $v $oldprefs($v)
}
catch {destroy $prefstop}
unset prefstop
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
fontcan
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
}
proc prefsok {} {
global maxwidth maxgraphpct
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
global oldprefs prefstop showneartags showlocalchanges
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
global fontpref mainfont textfont uifont
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
global limitdiffs treediffs perfile_attrs
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
global hideremotes
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
catch {destroy $prefstop}
unset prefstop
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
fontcan
set fontchanged 0
if {$mainfont ne $fontpref(mainfont)} {
set mainfont $fontpref(mainfont)
parsefont mainfont $mainfont
eval font configure mainfont [fontflags mainfont]
eval font configure mainfontbold [fontflags mainfont 1]
setcoords
set fontchanged 1
}
if {$textfont ne $fontpref(textfont)} {
set textfont $fontpref(textfont)
parsefont textfont $textfont
eval font configure textfont [fontflags textfont]
eval font configure textfontbold [fontflags textfont 1]
}
if {$uifont ne $fontpref(uifont)} {
set uifont $fontpref(uifont)
parsefont uifont $uifont
eval font configure uifont [fontflags uifont]
}
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
settabs
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
if {$showlocalchanges != $oldprefs(showlocalchanges)} {
if {$showlocalchanges} {
doshowlocalchanges
} else {
dohidelocalchanges
}
}
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
if {$limitdiffs != $oldprefs(limitdiffs) ||
($perfile_attrs && !$oldprefs(perfile_attrs))} {
# treediffs elements are limited by path;
# won't have encodings cached if perfile_attrs was just turned on
gitk: Fix a couple more bugs in the path limiting First, paths ending in a slash were not matching anything. This fixes path_filter to handle paths ending in a slash (such entries have to match a directory, and can't match a file, e.g., foo/bar/ can't match a plain file called foo/bar). Secondly, clicking in the file list pane (bottom right) was broken because $treediffs($ids) contained all the files modified by the commit, not just those within the file list. This fixes that too. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-24 02:16:56 +02:00
catch {unset treediffs}
}
gitk: Add a font chooser This adds buttons to the edit preferences window to allow the user to choose the main font, the text font (used for the diff display window) and the UI font. Pressing those buttons pops up a font chooser window that lets the user pick the font family, size, weight (bold/normal) and slant (roman/italic). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 12:16:06 +02:00
if {$fontchanged || $maxwidth != $oldprefs(maxwidth)
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
|| $maxgraphpct != $oldprefs(maxgraphpct)} {
redisplay
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
} elseif {$showneartags != $oldprefs(showneartags) ||
$limitdiffs != $oldprefs(limitdiffs)} {
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
reselectline
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
}
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
if {$hideremotes != $oldprefs(hideremotes)} {
rereadrefs
}
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
}
proc formatdate {d} {
[PATCH] gitk: Make the date/time display configurable The new 'datetimeformat' configuration variable in ~/.gitk can be set to a Tcl 'clock format' format string to modify the display of dates and times. http://www.tcl.tk/man/tcl8.4/TclCmd/clock.htm has a list of allowed fields. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-14 22:02:04 +02:00
global datetimeformat
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
if {$d ne {}} {
[PATCH] gitk: Make the date/time display configurable The new 'datetimeformat' configuration variable in ~/.gitk can be set to a Tcl 'clock format' format string to modify the display of dates and times. http://www.tcl.tk/man/tcl8.4/TclCmd/clock.htm has a list of allowed fields. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-14 22:02:04 +02:00
set d [clock format $d -format $datetimeformat]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
}
return $d
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
}
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
# This list of encoding names and aliases is distilled from
# http://www.iana.org/assignments/character-sets.
# Not all of them are supported by Tcl.
set encoding_aliases {
{ ANSI_X3.4-1968 iso-ir-6 ANSI_X3.4-1986 ISO_646.irv:1991 ASCII
ISO646-US US-ASCII us IBM367 cp367 csASCII }
{ ISO-10646-UTF-1 csISO10646UTF1 }
{ ISO_646.basic:1983 ref csISO646basic1983 }
{ INVARIANT csINVARIANT }
{ ISO_646.irv:1983 iso-ir-2 irv csISO2IntlRefVersion }
{ BS_4730 iso-ir-4 ISO646-GB gb uk csISO4UnitedKingdom }
{ NATS-SEFI iso-ir-8-1 csNATSSEFI }
{ NATS-SEFI-ADD iso-ir-8-2 csNATSSEFIADD }
{ NATS-DANO iso-ir-9-1 csNATSDANO }
{ NATS-DANO-ADD iso-ir-9-2 csNATSDANOADD }
{ SEN_850200_B iso-ir-10 FI ISO646-FI ISO646-SE se csISO10Swedish }
{ SEN_850200_C iso-ir-11 ISO646-SE2 se2 csISO11SwedishForNames }
{ KS_C_5601-1987 iso-ir-149 KS_C_5601-1989 KSC_5601 korean csKSC56011987 }
{ ISO-2022-KR csISO2022KR }
{ EUC-KR csEUCKR }
{ ISO-2022-JP csISO2022JP }
{ ISO-2022-JP-2 csISO2022JP2 }
{ JIS_C6220-1969-jp JIS_C6220-1969 iso-ir-13 katakana x0201-7
csISO13JISC6220jp }
{ JIS_C6220-1969-ro iso-ir-14 jp ISO646-JP csISO14JISC6220ro }
{ IT iso-ir-15 ISO646-IT csISO15Italian }
{ PT iso-ir-16 ISO646-PT csISO16Portuguese }
{ ES iso-ir-17 ISO646-ES csISO17Spanish }
{ greek7-old iso-ir-18 csISO18Greek7Old }
{ latin-greek iso-ir-19 csISO19LatinGreek }
{ DIN_66003 iso-ir-21 de ISO646-DE csISO21German }
{ NF_Z_62-010_(1973) iso-ir-25 ISO646-FR1 csISO25French }
{ Latin-greek-1 iso-ir-27 csISO27LatinGreek1 }
{ ISO_5427 iso-ir-37 csISO5427Cyrillic }
{ JIS_C6226-1978 iso-ir-42 csISO42JISC62261978 }
{ BS_viewdata iso-ir-47 csISO47BSViewdata }
{ INIS iso-ir-49 csISO49INIS }
{ INIS-8 iso-ir-50 csISO50INIS8 }
{ INIS-cyrillic iso-ir-51 csISO51INISCyrillic }
{ ISO_5427:1981 iso-ir-54 ISO5427Cyrillic1981 }
{ ISO_5428:1980 iso-ir-55 csISO5428Greek }
{ GB_1988-80 iso-ir-57 cn ISO646-CN csISO57GB1988 }
{ GB_2312-80 iso-ir-58 chinese csISO58GB231280 }
{ NS_4551-1 iso-ir-60 ISO646-NO no csISO60DanishNorwegian
csISO60Norwegian1 }
{ NS_4551-2 ISO646-NO2 iso-ir-61 no2 csISO61Norwegian2 }
{ NF_Z_62-010 iso-ir-69 ISO646-FR fr csISO69French }
{ videotex-suppl iso-ir-70 csISO70VideotexSupp1 }
{ PT2 iso-ir-84 ISO646-PT2 csISO84Portuguese2 }
{ ES2 iso-ir-85 ISO646-ES2 csISO85Spanish2 }
{ MSZ_7795.3 iso-ir-86 ISO646-HU hu csISO86Hungarian }
{ JIS_C6226-1983 iso-ir-87 x0208 JIS_X0208-1983 csISO87JISX0208 }
{ greek7 iso-ir-88 csISO88Greek7 }
{ ASMO_449 ISO_9036 arabic7 iso-ir-89 csISO89ASMO449 }
{ iso-ir-90 csISO90 }
{ JIS_C6229-1984-a iso-ir-91 jp-ocr-a csISO91JISC62291984a }
{ JIS_C6229-1984-b iso-ir-92 ISO646-JP-OCR-B jp-ocr-b
csISO92JISC62991984b }
{ JIS_C6229-1984-b-add iso-ir-93 jp-ocr-b-add csISO93JIS62291984badd }
{ JIS_C6229-1984-hand iso-ir-94 jp-ocr-hand csISO94JIS62291984hand }
{ JIS_C6229-1984-hand-add iso-ir-95 jp-ocr-hand-add
csISO95JIS62291984handadd }
{ JIS_C6229-1984-kana iso-ir-96 csISO96JISC62291984kana }
{ ISO_2033-1983 iso-ir-98 e13b csISO2033 }
{ ANSI_X3.110-1983 iso-ir-99 CSA_T500-1983 NAPLPS csISO99NAPLPS }
{ ISO_8859-1:1987 iso-ir-100 ISO_8859-1 ISO-8859-1 latin1 l1 IBM819
CP819 csISOLatin1 }
{ ISO_8859-2:1987 iso-ir-101 ISO_8859-2 ISO-8859-2 latin2 l2 csISOLatin2 }
{ T.61-7bit iso-ir-102 csISO102T617bit }
{ T.61-8bit T.61 iso-ir-103 csISO103T618bit }
{ ISO_8859-3:1988 iso-ir-109 ISO_8859-3 ISO-8859-3 latin3 l3 csISOLatin3 }
{ ISO_8859-4:1988 iso-ir-110 ISO_8859-4 ISO-8859-4 latin4 l4 csISOLatin4 }
{ ECMA-cyrillic iso-ir-111 KOI8-E csISO111ECMACyrillic }
{ CSA_Z243.4-1985-1 iso-ir-121 ISO646-CA csa7-1 ca csISO121Canadian1 }
{ CSA_Z243.4-1985-2 iso-ir-122 ISO646-CA2 csa7-2 csISO122Canadian2 }
{ CSA_Z243.4-1985-gr iso-ir-123 csISO123CSAZ24341985gr }
{ ISO_8859-6:1987 iso-ir-127 ISO_8859-6 ISO-8859-6 ECMA-114 ASMO-708
arabic csISOLatinArabic }
{ ISO_8859-6-E csISO88596E ISO-8859-6-E }
{ ISO_8859-6-I csISO88596I ISO-8859-6-I }
{ ISO_8859-7:1987 iso-ir-126 ISO_8859-7 ISO-8859-7 ELOT_928 ECMA-118
greek greek8 csISOLatinGreek }
{ T.101-G2 iso-ir-128 csISO128T101G2 }
{ ISO_8859-8:1988 iso-ir-138 ISO_8859-8 ISO-8859-8 hebrew
csISOLatinHebrew }
{ ISO_8859-8-E csISO88598E ISO-8859-8-E }
{ ISO_8859-8-I csISO88598I ISO-8859-8-I }
{ CSN_369103 iso-ir-139 csISO139CSN369103 }
{ JUS_I.B1.002 iso-ir-141 ISO646-YU js yu csISO141JUSIB1002 }
{ ISO_6937-2-add iso-ir-142 csISOTextComm }
{ IEC_P27-1 iso-ir-143 csISO143IECP271 }
{ ISO_8859-5:1988 iso-ir-144 ISO_8859-5 ISO-8859-5 cyrillic
csISOLatinCyrillic }
{ JUS_I.B1.003-serb iso-ir-146 serbian csISO146Serbian }
{ JUS_I.B1.003-mac macedonian iso-ir-147 csISO147Macedonian }
{ ISO_8859-9:1989 iso-ir-148 ISO_8859-9 ISO-8859-9 latin5 l5 csISOLatin5 }
{ greek-ccitt iso-ir-150 csISO150 csISO150GreekCCITT }
{ NC_NC00-10:81 cuba iso-ir-151 ISO646-CU csISO151Cuba }
{ ISO_6937-2-25 iso-ir-152 csISO6937Add }
{ GOST_19768-74 ST_SEV_358-88 iso-ir-153 csISO153GOST1976874 }
{ ISO_8859-supp iso-ir-154 latin1-2-5 csISO8859Supp }
{ ISO_10367-box iso-ir-155 csISO10367Box }
{ ISO-8859-10 iso-ir-157 l6 ISO_8859-10:1992 csISOLatin6 latin6 }
{ latin-lap lap iso-ir-158 csISO158Lap }
{ JIS_X0212-1990 x0212 iso-ir-159 csISO159JISX02121990 }
{ DS_2089 DS2089 ISO646-DK dk csISO646Danish }
{ us-dk csUSDK }
{ dk-us csDKUS }
{ JIS_X0201 X0201 csHalfWidthKatakana }
{ KSC5636 ISO646-KR csKSC5636 }
{ ISO-10646-UCS-2 csUnicode }
{ ISO-10646-UCS-4 csUCS4 }
{ DEC-MCS dec csDECMCS }
{ hp-roman8 roman8 r8 csHPRoman8 }
{ macintosh mac csMacintosh }
{ IBM037 cp037 ebcdic-cp-us ebcdic-cp-ca ebcdic-cp-wt ebcdic-cp-nl
csIBM037 }
{ IBM038 EBCDIC-INT cp038 csIBM038 }
{ IBM273 CP273 csIBM273 }
{ IBM274 EBCDIC-BE CP274 csIBM274 }
{ IBM275 EBCDIC-BR cp275 csIBM275 }
{ IBM277 EBCDIC-CP-DK EBCDIC-CP-NO csIBM277 }
{ IBM278 CP278 ebcdic-cp-fi ebcdic-cp-se csIBM278 }
{ IBM280 CP280 ebcdic-cp-it csIBM280 }
{ IBM281 EBCDIC-JP-E cp281 csIBM281 }
{ IBM284 CP284 ebcdic-cp-es csIBM284 }
{ IBM285 CP285 ebcdic-cp-gb csIBM285 }
{ IBM290 cp290 EBCDIC-JP-kana csIBM290 }
{ IBM297 cp297 ebcdic-cp-fr csIBM297 }
{ IBM420 cp420 ebcdic-cp-ar1 csIBM420 }
{ IBM423 cp423 ebcdic-cp-gr csIBM423 }
{ IBM424 cp424 ebcdic-cp-he csIBM424 }
{ IBM437 cp437 437 csPC8CodePage437 }
{ IBM500 CP500 ebcdic-cp-be ebcdic-cp-ch csIBM500 }
{ IBM775 cp775 csPC775Baltic }
{ IBM850 cp850 850 csPC850Multilingual }
{ IBM851 cp851 851 csIBM851 }
{ IBM852 cp852 852 csPCp852 }
{ IBM855 cp855 855 csIBM855 }
{ IBM857 cp857 857 csIBM857 }
{ IBM860 cp860 860 csIBM860 }
{ IBM861 cp861 861 cp-is csIBM861 }
{ IBM862 cp862 862 csPC862LatinHebrew }
{ IBM863 cp863 863 csIBM863 }
{ IBM864 cp864 csIBM864 }
{ IBM865 cp865 865 csIBM865 }
{ IBM866 cp866 866 csIBM866 }
{ IBM868 CP868 cp-ar csIBM868 }
{ IBM869 cp869 869 cp-gr csIBM869 }
{ IBM870 CP870 ebcdic-cp-roece ebcdic-cp-yu csIBM870 }
{ IBM871 CP871 ebcdic-cp-is csIBM871 }
{ IBM880 cp880 EBCDIC-Cyrillic csIBM880 }
{ IBM891 cp891 csIBM891 }
{ IBM903 cp903 csIBM903 }
{ IBM904 cp904 904 csIBBM904 }
{ IBM905 CP905 ebcdic-cp-tr csIBM905 }
{ IBM918 CP918 ebcdic-cp-ar2 csIBM918 }
{ IBM1026 CP1026 csIBM1026 }
{ EBCDIC-AT-DE csIBMEBCDICATDE }
{ EBCDIC-AT-DE-A csEBCDICATDEA }
{ EBCDIC-CA-FR csEBCDICCAFR }
{ EBCDIC-DK-NO csEBCDICDKNO }
{ EBCDIC-DK-NO-A csEBCDICDKNOA }
{ EBCDIC-FI-SE csEBCDICFISE }
{ EBCDIC-FI-SE-A csEBCDICFISEA }
{ EBCDIC-FR csEBCDICFR }
{ EBCDIC-IT csEBCDICIT }
{ EBCDIC-PT csEBCDICPT }
{ EBCDIC-ES csEBCDICES }
{ EBCDIC-ES-A csEBCDICESA }
{ EBCDIC-ES-S csEBCDICESS }
{ EBCDIC-UK csEBCDICUK }
{ EBCDIC-US csEBCDICUS }
{ UNKNOWN-8BIT csUnknown8BiT }
{ MNEMONIC csMnemonic }
{ MNEM csMnem }
{ VISCII csVISCII }
{ VIQR csVIQR }
{ KOI8-R csKOI8R }
{ IBM00858 CCSID00858 CP00858 PC-Multilingual-850+euro }
{ IBM00924 CCSID00924 CP00924 ebcdic-Latin9--euro }
{ IBM01140 CCSID01140 CP01140 ebcdic-us-37+euro }
{ IBM01141 CCSID01141 CP01141 ebcdic-de-273+euro }
{ IBM01142 CCSID01142 CP01142 ebcdic-dk-277+euro ebcdic-no-277+euro }
{ IBM01143 CCSID01143 CP01143 ebcdic-fi-278+euro ebcdic-se-278+euro }
{ IBM01144 CCSID01144 CP01144 ebcdic-it-280+euro }
{ IBM01145 CCSID01145 CP01145 ebcdic-es-284+euro }
{ IBM01146 CCSID01146 CP01146 ebcdic-gb-285+euro }
{ IBM01147 CCSID01147 CP01147 ebcdic-fr-297+euro }
{ IBM01148 CCSID01148 CP01148 ebcdic-international-500+euro }
{ IBM01149 CCSID01149 CP01149 ebcdic-is-871+euro }
{ IBM1047 IBM-1047 }
{ PTCP154 csPTCP154 PT154 CP154 Cyrillic-Asian }
{ Amiga-1251 Ami1251 Amiga1251 Ami-1251 }
{ UNICODE-1-1 csUnicode11 }
{ CESU-8 csCESU-8 }
{ BOCU-1 csBOCU-1 }
{ UNICODE-1-1-UTF-7 csUnicode11UTF7 }
{ ISO-8859-14 iso-ir-199 ISO_8859-14:1998 ISO_8859-14 latin8 iso-celtic
l8 }
{ ISO-8859-15 ISO_8859-15 Latin-9 }
{ ISO-8859-16 iso-ir-226 ISO_8859-16:2001 ISO_8859-16 latin10 l10 }
{ GBK CP936 MS936 windows-936 }
{ JIS_Encoding csJISEncoding }
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
{ Shift_JIS MS_Kanji csShiftJIS ShiftJIS Shift-JIS }
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
{ Extended_UNIX_Code_Packed_Format_for_Japanese csEUCPkdFmtJapanese
EUC-JP }
{ Extended_UNIX_Code_Fixed_Width_for_Japanese csEUCFixWidJapanese }
{ ISO-10646-UCS-Basic csUnicodeASCII }
{ ISO-10646-Unicode-Latin1 csUnicodeLatin1 ISO-10646 }
{ ISO-Unicode-IBM-1261 csUnicodeIBM1261 }
{ ISO-Unicode-IBM-1268 csUnicodeIBM1268 }
{ ISO-Unicode-IBM-1276 csUnicodeIBM1276 }
{ ISO-Unicode-IBM-1264 csUnicodeIBM1264 }
{ ISO-Unicode-IBM-1265 csUnicodeIBM1265 }
{ ISO-8859-1-Windows-3.0-Latin-1 csWindows30Latin1 }
{ ISO-8859-1-Windows-3.1-Latin-1 csWindows31Latin1 }
{ ISO-8859-2-Windows-Latin-2 csWindows31Latin2 }
{ ISO-8859-9-Windows-Latin-5 csWindows31Latin5 }
{ Adobe-Standard-Encoding csAdobeStandardEncoding }
{ Ventura-US csVenturaUS }
{ Ventura-International csVenturaInternational }
{ PC8-Danish-Norwegian csPC8DanishNorwegian }
{ PC8-Turkish csPC8Turkish }
{ IBM-Symbols csIBMSymbols }
{ IBM-Thai csIBMThai }
{ HP-Legal csHPLegal }
{ HP-Pi-font csHPPiFont }
{ HP-Math8 csHPMath8 }
{ Adobe-Symbol-Encoding csHPPSMath }
{ HP-DeskTop csHPDesktop }
{ Ventura-Math csVenturaMath }
{ Microsoft-Publishing csMicrosoftPublishing }
{ Windows-31J csWindows31J }
{ GB2312 csGB2312 }
{ Big5 csBig5 }
}
proc tcl_encoding {enc} {
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
global encoding_aliases tcl_encoding_cache
if {[info exists tcl_encoding_cache($enc)]} {
return $tcl_encoding_cache($enc)
}
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
set names [encoding names]
set lcnames [string tolower $names]
set enc [string tolower $enc]
set i [lsearch -exact $lcnames $enc]
if {$i < 0} {
# look for "isonnn" instead of "iso-nnn" or "iso_nnn"
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
if {[regsub {^(iso|cp|ibm|jis)[-_]} $enc {\1} encx]} {
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
set i [lsearch -exact $lcnames $encx]
}
}
if {$i < 0} {
foreach l $encoding_aliases {
set ll [string tolower $l]
if {[lsearch -exact $ll $enc] < 0} continue
# look through the aliases for one that tcl knows about
foreach e $ll {
set i [lsearch -exact $lcnames $e]
if {$i < 0} {
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
if {[regsub {^(iso|cp|ibm|jis)[-_]} $e {\1} ex]} {
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
set i [lsearch -exact $lcnames $ex]
}
}
if {$i >= 0} break
}
break
}
}
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
set tclenc {}
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
if {$i >= 0} {
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
set tclenc [lindex $names $i]
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
}
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
set tcl_encoding_cache($enc) $tclenc
return $tclenc
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
proc gitattr {path attr default} {
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
global path_attr_cache
if {[info exists path_attr_cache($attr,$path)]} {
set r $path_attr_cache($attr,$path)
} else {
set r "unspecified"
if {![catch {set line [exec git check-attr $attr -- $path]}]} {
gitk: Do not hard-code "encoding" in attribute lookup functions Commit 39ee47e (Clean up file encoding code and add enable/disable option, 2008-10-15) rewrote the attribute lookup functions gitattr and cache_gitattr, but in the process hard-coded the attribute name "encoding" instead of using the functions' parameters. This fixes it. This is not a serious regression because currently all callers look only for "encoding". Further note that this fix assumes that future callers will not pass an attribute name that contains regex special characters. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-07-21 10:09:48 +02:00
regexp "(.*): $attr: (.*)" $line m f r
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
}
gitk: Implement batch lookup and caching of encoding attrs When the diff contains thousands of files, calling git-check-attr once per file is very slow. With this patch gitk does attribute lookup in batches of 30 files while reading the diff file list, which leads to a very noticeable speedup. It may be possible to reimplement this even more efficiently, if git-check-attr is modified to support a --stdin-paths option. Additionally, it should quote the ':' character in file paths, or provide a more robust way of column separation. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:33 +02:00
set path_attr_cache($attr,$path) $r
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
}
if {$r eq "unspecified"} {
return $default
}
return $r
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
}
gitk: Implement batch lookup and caching of encoding attrs When the diff contains thousands of files, calling git-check-attr once per file is very slow. With this patch gitk does attribute lookup in batches of 30 files while reading the diff file list, which leads to a very noticeable speedup. It may be possible to reimplement this even more efficiently, if git-check-attr is modified to support a --stdin-paths option. Additionally, it should quote the ':' character in file paths, or provide a more robust way of column separation. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:33 +02:00
proc cache_gitattr {attr pathlist} {
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
global path_attr_cache
set newlist {}
foreach path $pathlist {
if {![info exists path_attr_cache($attr,$path)]} {
lappend newlist $path
}
}
set lim 1000
if {[tk windowingsystem] == "win32"} {
# windows has a 32k limit on the arguments to a command...
set lim 30
}
while {$newlist ne {}} {
set head [lrange $newlist 0 [expr {$lim - 1}]]
set newlist [lrange $newlist $lim end]
if {![catch {set rlist [eval exec git check-attr $attr -- $head]}]} {
foreach row [split $rlist "\n"] {
gitk: Do not hard-code "encoding" in attribute lookup functions Commit 39ee47e (Clean up file encoding code and add enable/disable option, 2008-10-15) rewrote the attribute lookup functions gitattr and cache_gitattr, but in the process hard-coded the attribute name "encoding" instead of using the functions' parameters. This fixes it. This is not a serious regression because currently all callers look only for "encoding". Further note that this fix assumes that future callers will not pass an attribute name that contains regex special characters. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-07-21 10:09:48 +02:00
if {[regexp "(.*): $attr: (.*)" $row m path value]} {
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
if {[string index $path 0] eq "\""} {
set path [encoding convertfrom [lindex $path 0]]
}
set path_attr_cache($attr,$path) $value
gitk: Implement batch lookup and caching of encoding attrs When the diff contains thousands of files, calling git-check-attr once per file is very slow. With this patch gitk does attribute lookup in batches of 30 files while reading the diff file list, which leads to a very noticeable speedup. It may be possible to reimplement this even more efficiently, if git-check-attr is modified to support a --stdin-paths option. Additionally, it should quote the ':' character in file paths, or provide a more robust way of column separation. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:33 +02:00
}
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
}
gitk: Implement batch lookup and caching of encoding attrs When the diff contains thousands of files, calling git-check-attr once per file is very slow. With this patch gitk does attribute lookup in batches of 30 files while reading the diff file list, which leads to a very noticeable speedup. It may be possible to reimplement this even more efficiently, if git-check-attr is modified to support a --stdin-paths option. Additionally, it should quote the ':' character in file paths, or provide a more robust way of column separation. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:33 +02:00
}
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
}
gitk: Implement batch lookup and caching of encoding attrs When the diff contains thousands of files, calling git-check-attr once per file is very slow. With this patch gitk does attribute lookup in batches of 30 files while reading the diff file list, which leads to a very noticeable speedup. It may be possible to reimplement this even more efficiently, if git-check-attr is modified to support a --stdin-paths option. Additionally, it should quote the ':' character in file paths, or provide a more robust way of column separation. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:33 +02:00
}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
proc get_path_encoding {path} {
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
global gui_encoding perfile_attrs
set tcl_enc $gui_encoding
if {$path ne {} && $perfile_attrs} {
set enc2 [tcl_encoding [gitattr $path encoding $tcl_enc]]
if {$enc2 ne {}} {
set tcl_enc $enc2
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
}
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
}
return $tcl_enc
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
}
gitk: Check that we are running on at least Tcl/Tk 8.4 This checks that we have Tcl/Tk 8.4 or later, and puts up an error message in a window and quits if not. This was prompted by a patch submitted by Steffen Prohaska, but is done a bit differently (this uses package require rather than looking at [info tclversion], and uses show_error to display the error rather than printing it to stderr). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-20 13:21:03 +02:00
# First check that Tcl/Tk is recent enough
if {[catch {package require Tk 8.4} err]} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
show_error {} . [mc "Sorry, gitk cannot run with this version of Tcl/Tk.\n\
Gitk requires at least Tcl/Tk 8.4."]
gitk: Check that we are running on at least Tcl/Tk 8.4 This checks that we have Tcl/Tk 8.4 or later, and puts up an error message in a window and quits if not. This was prompted by a patch submitted by Steffen Prohaska, but is done a bit differently (this uses package require rather than looking at [info tclversion], and uses show_error to display the error rather than printing it to stderr). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-20 13:21:03 +02:00
exit 1
}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
# defaults...
[PATCH] gitk: Replace "git-" commands with "git " git-* commands work only if gitexecdir is in PATH. Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 09:57:40 +02:00
set wrcomcmd "git diff-tree --stdin -p --pretty"
[PATCH] gitk: Use i18n.commitencoding configuration item. Hardcoding "utf-8" in the script breaks projects that use local encoding, so allow setting i18n.commitEncoding. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-28 01:12:51 +01:00
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
set gitencoding {}
[PATCH] gitk: Use i18n.commitencoding configuration item. Hardcoding "utf-8" in the script breaks projects that use local encoding, so allow setting i18n.commitEncoding. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-28 01:12:51 +01:00
catch {
Change git repo-config to git config This is the gitk part of e0d10e1c63bc52b37bbec99b07deee794058d9b4 from Tom Prince. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-02-14 22:54:34 +01:00
set gitencoding [exec git config --get i18n.commitencoding]
[PATCH] gitk: Use i18n.commitencoding configuration item. Hardcoding "utf-8" in the script breaks projects that use local encoding, so allow setting i18n.commitEncoding. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-28 01:12:51 +01:00
}
gitk: Fix commit encoding support This commit fixes two problems with commit encodings: 1) git-log actually uses i18n.logoutputencoding to generate its output, and falls back to i18n.commitencoding only when that option is not set. Thus, gitk should use its value to read the results, if available. 2) The readcommit function did not process encodings at all. This led to randomly appearing misconverted commits if the commit encoding differed from the current locale. Now commit messages should be displayed correctly, except when logoutputencoding is set to an encoding that cannot represent charecters in the message. For example, it is impossible to convert Japanese characters from Shift-JIS to CP-1251 (although the reverse conversion works). The reason for using git log to read the commit and then getting Tcl to convert its output is that is essentially what happens in the normal path through getcommitlines, hence there is less chance for unintended differences in how commits are processed in getcommitlines and do_readcommit. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-09 16:06:07 +01:00
catch {
set gitencoding [exec git config --get i18n.logoutputencoding]
}
[PATCH] gitk: Use i18n.commitencoding configuration item. Hardcoding "utf-8" in the script breaks projects that use local encoding, so allow setting i18n.commitEncoding. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-28 01:12:51 +01:00
if {$gitencoding == ""} {
gitk: Work around Tcl's non-standard names for encodings This uses a table of encoding names and aliases distilled from http://www.iana.org/assignments/character-sets plus some heuristics to convert standard encoding names to ones that Tcl recognizes. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-12-07 13:28:22 +01:00
set gitencoding "utf-8"
}
set tclencoding [tcl_encoding $gitencoding]
if {$tclencoding == {}} {
puts stderr "Warning: encoding $gitencoding is not supported by Tcl/Tk"
[PATCH] gitk: Use i18n.commitencoding configuration item. Hardcoding "utf-8" in the script breaks projects that use local encoding, so allow setting i18n.commitEncoding. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-28 01:12:51 +01:00
}
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
set gui_encoding [encoding system]
catch {
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
set enc [exec git config --get gui.encoding]
if {$enc ne {}} {
set tclenc [tcl_encoding $enc]
if {$tclenc ne {}} {
set gui_encoding $tclenc
} else {
puts stderr "Warning: encoding $enc is not supported by Tcl/Tk"
}
}
gitk: Enhance file encoding support This allows the encoding to be specified for file contents and used when displaying files and diffs in the bottom-left pane. When displaying diffs, the encoding for each diff hunk is that for the file that the diff hunk is from, so it can change through the course of the diff. The encoding for file contents is determined as follows: - File encoding defaults to the system encoding. - It can be overridden by setting the gui.encoding option. - Finally, the 'encoding' attribute is checked on per-file basis; it has the last word. Note: Since git-check-attr does not provide support for reading attributes from trees, attribute lookup is done using files from the working directory. This also extends the range of supported encoding names, adding ShiftJIS and Shift-JIS as aliases for Shift_JIS, and allowing cp-*, cp_*, ibm-*, ibm_*, jis-* and jis_* as aliases for cp*, ibm* and jis* respectively. This also fixes some bugs in handling of non-ASCII filenames. Core git apparently supports only locale-encoded filenames, so processing is done using the system encoding. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-13 10:12:31 +02:00
}
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
if {[tk windowingsystem] eq "aqua"} {
set mainfont {{Lucida Grande} 9}
set textfont {Monaco 9}
set uifont {{Lucida Grande} 9 bold}
} else {
set mainfont {Helvetica 9}
set textfont {Courier 9}
set uifont {Helvetica 9 bold}
}
[PATCH] gitk: Allow specifying tabstop as other than default 8 characters. Not all projects use the convention that one tabstop = 8 characters, and a common convention is to use one tabstop = one level of indent. For such projects, using 8 characters per tabstop often shows too much whitespace per indent. This allows the user to configure the number of characters to use per tabstop. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 17:45:50 +02:00
set tabstop 8
Add "Files" and "Pickaxe" to the find menu. "Files" matches the find string against each of the files modified by each commit, and can do exact, case-ignoring or regexp matching. "Pickaxe" uses git-diff-tree -S'string' and can only do exact matching. I called it "pickaxe" rather than "find within patch" since it only finds commits where the string is present in the child but not the parents or vice versa, and "pickaxe" is what the author of that feature calls it.
2005-07-16 13:46:13 +02:00
set findmergefiles 0
Compress the graph horizontally if it gets too wide. If the graph gets to use more than a certain percentage (default 50%) of the width of the top-left pane, we now reduce the amount of space allowed for each graph line. This means it doesn't look quite as nice but you can still see the headline for the commit. (Currently the only way to customize the percentage is to edit your ~/.gitk file manually.)
2005-08-05 01:52:16 +02:00
set maxgraphpct 50
Allow graph lines to jump through hyperspace. When the graph gets too wide (as defined by the maxwidth variable, which can be set in ~/.gitk), we can now terminate graph lines with an arrow pointing downwards, and reintroduce them later with an arrow pointing upwards when we need them. This makes the graph much less cluttered on large repositories such as the linux kernel. Unfortunately this has made it slower; it takes about 10 seconds user time on the linux-2.6 repository on my machine now, compared to 6 seconds before. I'll have to work on optimizing that. Also on the todo list are making the arrow heads active (so if you click on them you jump to the other end) and improving the placement of the null entry.
2005-08-18 01:30:10 +02:00
set maxwidth 16
Add -r flag and some speedups The -r flag means "rev-list order", i.e. just display the commits in the order they come from git-rev-list. The speedups include: - don't process the whole commit line-by-line, only the header - don't convert dates when reading the commits, rather do it when needed - don't do the $canv delete lines.$id in drawlines when drawing the graph initially (it was taking a lot of the total time) - cache the date conversion for each hour (more important with tk8.5, since [clock format] is a lot slower in 8.5 than in 8.4). Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-15 00:34:03 +01:00
set revlistorder 0
gitk: Disable fastdate stuff for now It has a fatal flaw in that it only handles timezones that are a multiple of an hour. It's really only needed with Tk8.5, where the clock format command has been reimplemented in Tcl and is much slower than in Tk8.4. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-20 23:56:07 +01:00
set fastdate 0
gitk: Establish and use global left-to-right ordering for commits This creates an "ordering token" for each commit which establishes a total ordering for commits and is used to order the commits from left to right on a row. The ordering token is assigned when a commit is first encountered or when it is first listed as a parent of some other commit, whichever comes first. The ordering token is a string of variable length. Parents that don't already have an ordering token are assigned one by appending to the child's token; the first parent gets a "0" on the end, the second "1" and so on. As an optimization, the "0" isn't appended if the child only has one parent. When inserting a new commit into an element of rowidlist, it is inserted in the position which makes the ordering tokens increase from left to right. This also simplifies the layout code by getting rid of the rowoffsets variable, and terminates lines with an arrow after 5 rows if the line would be longer than about 110 rows (rather than letting them go on and terminating them later with an arrow if the graph gets too wide). The effect of having the total ordering, and terminating the lines early, is that it will be possible to lay out only a part of the graph rather than having to do the whole thing top to bottom. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-31 13:03:06 +02:00
set uparrowlen 5
set downarrowlen 5
set mingaplen 100
gitk: Add a tree-browsing mode You can now select whether you want to see the patch for a commit or the whole tree. If you select the tree, gitk will now display the commit message plus the contents of one file in the bottom-left pane, when you click on the name of the file in the bottom-right pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-01 01:50:57 +02:00
set cmitmode "patch"
[PATCH] gitk: Display commit messages with word wrap Some people put very long strings into commit messages, which then become invisible in gitk (word wrapping in the commit details window is turned off, and there is no horizontal scroll bar). Enabling word wrap for just the commit message looks much better. Wrapping is controlled by the "wrapcomment" option in ~/.gitk. By default this option is set to "none", which disables wrapping; setting it to "word" enables word wrap for commit messages. Signed-off-by: Sergey Vlasov <vsu@altlinux.ru> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-15 17:13:14 +02:00
set wrapcomment "none"
gitk: Show nearby tags This adds a feature to the diff display window where it will show the tags that this commit follows (is a descendent of) and precedes (is an ancestor of). Specifically, it will show the tags for all tagged descendents that are not a descendent of another tagged descendent of this commit, and the tags for all tagged ancestors that are not ancestors of another tagged ancestor of this commit. To do this, gitk reads the complete commit graph using git rev-list and performs a couple of traversals of the tree. This is done in the background, but since it can be time-consuming, there is an option to turn it off in the `edit preferences' window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-06-03 11:11:13 +02:00
set showneartags 1
gitk: New option to hide remote refs In repositories with lots of remotes, looking at the history in gitk can be borderline insane with all the red labels for remote refs. Introduce a new option in the preferences that makes gitk ignore remote refs entirely, so they don't take up space in the display. Wished-for-by: Thell Fowler <tbfowler4@gmail.com> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-08-03 23:53:36 +02:00
set hideremotes 0
gitk: Don't try to list large numbers of tags or heads in the details pane With some large repositories, a commit can end up on thousands of branches, which results in an extremely long "Branches:" line in the details window, and that results in the window being extremely slow to scroll. This fixes it by just showing "many (N)" after "Branches:", "Follows:" or "Precedes:", where N is the number of heads or tags. The limit is currently set at 20 but could be made configurable (and the "many" could be a link to pop up a window listing them all in case anyone really wants to know). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-16 13:21:57 +02:00
set maxrefs 20
gitk: New algorithm for drawing the graph lines This only draws as much of the graph lines as is visible. This can happen by adding coordinates on to an existing graph line or by creating a new line. This means that we only need to have laid out and optimized as much of the graph as is actually visible in order to draw it, including the lines (previously we didn't draw a graph line until we had laid out and optimized to the end of a segment of the line, i.e. down to a down-arrow or to the row where the line's commit is displayed). This also lets us get rid of the linesegends list, and gives us an easy workaround for the X server bug that causes long lines to be misdrawn. This also gets rid of the use of rowoffsets in drawlineseg et al. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-10-15 10:03:46 +02:00
set maxlinelen 200
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set showlocalchanges 1
gitk: Limit diff display to listed paths by default When the user has specified a list of paths, either on the command line or when creating a view, gitk currently displays the diffs for all files that a commit has modified, not just the ones that match the path list. This is different from other git commands such as git log. This change makes gitk behave the same as these other git commands by default, that is, gitk only displays the diffs for files that match the path list. There is now a checkbox labelled "Limit diffs to listed paths" in the Edit/Preferences pane. If that is unchecked, gitk will display the diffs for all files as before. When gitk is run with the --merge flag, it will get the list of unmerged files at startup, intersect that with the paths listed on the command line (if any), and use that as the list of paths. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-23 02:15:11 +02:00
set limitdiffs 1
[PATCH] gitk: Make the date/time display configurable The new 'datetimeformat' configuration variable in ~/.gitk can be set to a Tcl 'clock format' format string to modify the display of dates and times. http://www.tcl.tk/man/tcl8.4/TclCmd/clock.htm has a list of allowed fields. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-14 22:02:04 +02:00
set datetimeformat "%Y-%m-%d %H:%M:%S"
[PATCH] gitk: make autoselect optional Whenever a commit is selected in the graph pane, its SHA1 is automatically put into the selection buffer for cut and paste. However, some users may find this behavior annoying since it can overwrite something they actually wanted to keep in the buffer. This makes the behavior optional under the name "Auto-select SHA1", but continues to default to "on". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-06 12:49:25 +01:00
set autoselect 1
gitk: Clean up file encoding code and add enable/disable option This adds an option allowing the user to select whether gitk should look up per-file encoding settings using git check-attr or not. If not, gitk uses the global encoding set in the git config (as reported by git config --get gui.encoding) for all files, or if that is not set, then the system encoding. The option is controlled by a checkbox in the Edit->Preferences window, and defaults to off for now because git check-attr is so slow. When the user turns it on we discard any cached diff file lists in treediffs, because we may not have encodings cached for the files listed in those lists, meaning that getblobdiffline will do it for each file, which will be really really slow. This adjusts the limit of how many paths cache_gitattr passes to each instance of git check-attr depending on whether we're running under windows or not. Passing only 30 doesn't effectively amortize the startup costs of git check-attr, but it's all we can do under windows because of the 32k limit on arguments to a command. Under other OSes we pass up to 1000. Similarly we adjust how many lines gettreediffline processes depending on whether we are doing per-file encodings so that we don't run for too long. When we are, 500 seems to be a reasonable limit, leading to gettreediffline taking about 60-70ms under Linux (almost all of which is in cache_gitattr, unfortunately). This means that we can take out the update call in cache_gitattr. This adds a simple cache on [tclencoding]. Now that we get repeated calls to translate the same encoding, this is useful. This reindents the new code added in the last couple of commits to conform to the gitk 4-space indent and makes various other improvements: use regexp in gitattr and cache_gitattr instead of split + join + regsub, make gui_encoding be the value from [tclencoding] to avoid having to do [tcl_encoding $gui_encoding] in each call to get_path_encoding, and print a warning message at startup if $gui_encoding isn't supported by Tcl. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-15 13:23:03 +02:00
set perfile_attrs 0
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
gitk: Fixes for Mac OS X TkAqua - middle button is B3 on TkAqua - add horizontal mousehweel scrolling - nicer default fonts - use OSX-specific extdifftool - remove quit menu item, call doquit on quit event - move about & preferences menu items into apple menu - don't set menu font Signed-off-by: Daniel A. Steffen <das@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-23 12:17:38 +01:00
if {[tk windowingsystem] eq "aqua"} {
set extdifftool "opendiff"
} else {
set extdifftool "meld"
}
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
set colors {green red blue magenta darkgrey brown orange}
gitk: Allow the user to set some colors This makes the colors for the diff old/new lines and hunk headers configurable, as well as the background and foreground (text color) of the various panes. There is now a GUI in the edit->preferences window to set them. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-07-05 14:56:37 +02:00
set bgcolor white
set fgcolor black
set diffcolors {red "#00a000" blue}
[PATCH] gitk: Let user easily specify lines of context in diff view More lines of context sometimes help to better understand a diff. This patch introduces a text field above the box displaying the blobdiffs. You can type in the number of lines of context that you wish to view. The number of lines of context is saved to ~/.gitk. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-12 12:05:46 +02:00
set diffcontext 3
[PATCH] gitk: Add checkbutton to ignore space changes Ignoring space changes can be helpful. For example, a commit claims to only reformat source code and you quickly want to verify if this claim is true. Or a commit accidentally changes code formatting and you want to focus on the real changes. In such cases a button to toggle of whitespace changes would be quite handy. You could quickly toggle between seeing and ignoring whitespace changes. This commit adds such a checkbutton right above the diff view. However, in general it is a good thing to see whitespace changes and therefore the state of the checkbutton is not saved. For example, space changes might happen unintentionally. But they are real changes yielding different sha1s for the blobs involved. Signed-off-by: Steffen Prohaska <prohaska@zib.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-17 23:42:55 +01:00
set ignorespace 0
[PATCH] gitk: Make selection highlight color configurable Cygwin's tk by default uses a very dark selection background color that makes the currently selected text almost unreadable. On linux, the default selection background is a light gray which is very usable. This makes the default a light gray everywhere but allows the user to configure the color as well. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-05-20 18:12:48 +02:00
set selectbgcolor gray85
gitk: Make the background color of marked lines configurable This makes it possible for the user to configure the background color of lines that are "marked". At the moment only the "show the origin of this line" function marks lines. This also makes the user's choice persistent by saving it in ~/.gitk. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-27 12:37:21 +01:00
set markbgcolor "#e0e0ff"
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
gitk: Handle detached heads better This draws the currently checked-out head with a yellow circle, as suggested by Linus Torvalds, and fixes various places in the code where we assumed that the current head always had a branch. Now we can display the fake commits for local changes on a detached head. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-26 02:11:33 +02:00
set circlecolors {white blue gray blue blue}
gitk: Use <Button-2> for context menus on OSX An OSX user has reported that gitk's context menus are not usable under OSX because it doesn't provide a way to generate <Button-3> events. Users can generate <Button-2> events with command+click, so use that for the context menus instead on OSX. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-09-22 01:11:37 +02:00
# button for popping up context menus
if {[tk windowingsystem] eq "aqua"} {
set ctxbut <Button-2>
} else {
set ctxbut <Button-3>
}
[PATCH] gitk i18n: Import msgcat for message string translation; load translation catalogs By setting the environment variable GITK_MSGSDIR, one can manually set the directory where the .msg files are located. This is quite handy during development with GITK_MSGSDIR=po. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:40:59 +01:00
## For msgcat loading, first locate the installation location.
if { [info exists ::env(GITK_MSGSDIR)] } {
## Msgsdir was manually set in the environment.
set gitk_msgsdir $::env(GITK_MSGSDIR)
} else {
## Let's guess the prefix from argv0.
set gitk_prefix [file dirname [file dirname [file normalize $argv0]]]
set gitk_libdir [file join $gitk_prefix share gitk lib]
set gitk_msgsdir [file join $gitk_libdir msgs]
unset gitk_prefix
}
## Internationalization (i18n) through msgcat and gettext. See
## http://www.gnu.org/software/gettext/manual/html_node/Tcl.html
package require msgcat
namespace import ::msgcat::mc
## And eventually load the actual message catalog
::msgcat::mcload $gitk_msgsdir
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
catch {source ~/.gitk}
gitk: Add a preferences dialog with some basic stuff There is a lot more that could be put in, such as a selector for the font family etc., but this is a start. Signed-off-by: Paul Mackerras <paulus@samba.org>
2005-11-29 23:28:16 +01:00
font create optionfont -family sans-serif -size -12
More fixes for geometry restoration Make up/down/pgup/pgdn work again Return in find string entry does find Scale circles and lines with font size Fix scrolling to make entire selected line visible Use white circle for commits not listed but put in to terminate lines Fix diff parsing for created and deleted files
2005-05-19 00:51:00 +02:00
gitk: Keep track of font attributes ourselves instead of using font actual Unfortunately there seems to be a bug in Tk8.5 where font actual -size sometimes gives the wrong answer (e.g. 12 for Bitstream Vera Sans 9), even though the font is actually displayed at the right size. This works around it by parsing and storing the family, size, weight and slant of the mainfont, textfont and uifont explicitly. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-10-06 10:27:37 +02:00
parsefont mainfont $mainfont
eval font create mainfont [fontflags mainfont]
eval font create mainfontbold [fontflags mainfont 1]
parsefont textfont $textfont
eval font create textfont [fontflags textfont]
eval font create textfontbold [fontflags textfont 1]
parsefont uifont $uifont
eval font create uifont [fontflags uifont]
More fixes for geometry restoration Make up/down/pgup/pgdn work again Return in find string entry does find Scale circles and lines with font size Fix scrolling to make entire selected line visible Use white circle for commits not listed but put in to terminate lines Fix diff parsing for created and deleted files
2005-05-19 00:51:00 +02:00
gitk: Restore some widget options whose defaults changed in Tk 8.5 The default options for panedwindows in Tk 8.5 make the sash virtually invisible -- the handle is not shown and the relief is flat. This puts the defaults back to showing the handle and a raised relief on the sash, as in Tk 8.4. This uses the option command to do this, and also uses the option command to set the default font for various UI elements to the UI font ("uifont"). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-01-06 05:54:46 +01:00
setoptions
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
# check that we can find a .git directory somewhere...
[PATCH] gitk: Show an error and exit if no .git could be found This is to help people starting gitk from graphical file managers where the stderr output is hidden. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-29 22:29:45 +02:00
if {[catch {set gitdir [gitdir]}]} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
show_error {} . [mc "Cannot find a git repository here."]
[PATCH] gitk: Show an error and exit if no .git could be found This is to help people starting gitk from graphical file managers where the stderr output is hidden. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-29 22:29:45 +02:00
exit 1
}
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
if {![file isdirectory $gitdir]} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
show_error {} . [mc "Cannot find the git directory \"%s\"." $gitdir]
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
exit 1
}
gitk: Add option to specify the default commit on command line Other GUI tools may need to start gitk and make it automatically select a certain commit. This adds a new command-line option --select-commit=id to make that possible. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:27:44 +02:00
set selecthead {}
set selectheadid {}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
set revtreeargs {}
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
set cmdline_files {}
set i 0
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
set revtreeargscmd {}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
foreach arg $argv {
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
switch -glob -- $arg {
gitk: Fix bug introduced by previous commit When I added the "--" case to the code scanning the arguments, I missed the fact that since the switch statement uses -regexp, the "--" case will match any argument containing "--", e.g. "--all". This fixes it by taking out the -regexp (since we don't actually need regular expression matching) and adjusting the match strings. A side effect of this is that previously any argument starting with "-d" would be taken to indicate date mode; now the argument has to be exactly "-d" if you want date mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 05:45:55 +02:00
"" { }
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
"--" {
set cmdline_files [lrange $argv [expr {$i + 1}] end]
break
}
gitk: Add option to specify the default commit on command line Other GUI tools may need to start gitk and make it automatically select a certain commit. This adds a new command-line option --select-commit=id to make that possible. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:27:44 +02:00
"--select-commit=*" {
set selecthead [string range $arg 16 end]
}
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
"--argscmd=*" {
set revtreeargscmd [string range $arg 10 end]
}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
default {
lappend revtreeargs $arg
}
}
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
incr i
Add initial version of gitk to the CVS repository
2005-05-09 06:08:39 +02:00
}
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
gitk: Add option to specify the default commit on command line Other GUI tools may need to start gitk and make it automatically select a certain commit. This adds a new command-line option --select-commit=id to make that possible. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-08-23 10:27:44 +02:00
if {$selecthead eq "HEAD"} {
set selecthead {}
}
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
if {$i >= [llength $argv] && $revtreeargs ne {}} {
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
# no -- on command line, but some arguments (other than --argscmd)
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
if {[catch {
[PATCH] gitk: Replace "git-" commands with "git " git-* commands work only if gitexecdir is in PATH. Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-24 09:57:40 +02:00
set f [eval exec git rev-parse --no-revs --no-flags $revtreeargs]
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
set cmdline_files [split $f "\n"]
set n [llength $cmdline_files]
set revtreeargs [lrange $revtreeargs 0 end-$n]
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
# Unfortunately git rev-parse doesn't produce an error when
# something is both a revision and a filename. To be consistent
# with git log and git rev-list, check revtreeargs for filenames.
foreach arg $revtreeargs {
if {[file exists $arg]} {
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
show_error {} . [mc "Ambiguous argument '%s': both revision\
and filename" $arg]
gitk: Improve handling of -- and ambiguous arguments This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-12 14:29:49 +02:00
exit 1
}
}
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
} err]} {
# unfortunately we get both stdout and stderr in $err,
# so look for "fatal:".
set i [string first "fatal:" $err]
if {$i > 0} {
[PATCH] gitk: start-up bugfix The code to extract a message part from the error message was not passing the error message to [string range], and resulted in the show_error not getting called. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-26 09:07:15 +02:00
set err [string range $err [expr {$i + 6}] end]
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
}
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
show_error {} . "[mc "Bad arguments to gitk:"]\n$err"
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
exit 1
}
}
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set nullid "0000000000000000000000000000000000000000"
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
set nullid2 "0000000000000000000000000000000000000001"
gitk: Allow users to view diffs in external diff viewer This allows gitk to run an external diff viewer such as meld. Right-click on a file in the file list view gives "External diff" popup menu entry, which launches the selected external diff tool. The menu entry is only active in "Patch" mode, not in "Tree" mode. The program to run to display the diff is configurable through Edit/Preference/External diff tool. The program is run with two arguments, being the names of files containing the two versions to diff. Gitk will create temporary directories called .gitk-tmp.<pid>/<n> to place these files in, and remove them when it's finished. If the file doesn't exist in one or other revision, gitk will supply /dev/null as the name of the file on that side of the diff. This may need to be adjusted for Windows or MacOS. [paulus@samba.org - cleaned up and rewrote some parts of the patch.] Signed-off-by: Thomas Arcila <thomas.arcila@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-24 12:55:36 +01:00
set nullfile "/dev/null"
gitk: Show changes in index and changes in working directory separately This makes gitk show up to two fake commits when there are local changes in the repository; one to represent the state of the index and one to represent the state of the working directory. The commit representing the working directory is colored red as before; the commit representing the index state is colored magenta (as being between red and blue in some sense). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-13 11:49:37 +02:00
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
set have_tk85 [expr {[package vcompare $tk_version "8.5"] >= 0}]
gitk: Handle msysGit version during version comparisons msysGit generates version strings with text appended which cannot be used with vcompare; trying to use them generates a Tcl error. Limit git_version to the first three digits which are the real git version to avoid this error. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-05-18 23:46:01 +02:00
set git_version [join [lrange [split [lindex [exec git version] end] .] 0 2] .]
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
gitk: Implement a simple scheduler for the compute-intensive stuff This allows us to do compute-intensive processing, such as laying out the graph, relatively efficiently while also having the GUI be reasonably responsive. The problem previously was that file events were serviced before X events, so reading from another process which supplies data quickly (hi git rev-list :) could mean that X events didn't get processed for a long time. With this, gitk finishes laying out the graph slightly sooner and still responds to the GUI while doing so. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-06-17 06:45:00 +02:00
set runq {}
Add forward and back buttons and make SHA1 IDs clickable links. When we display the commit message in the details pane, any string of 40 [0-9a-f] characters that corresponds to a SHA1 ID that we know about gets turned into a clickable link, and displayed in blue and underlined. We now keep a history of commits that we have looked at, and we have forward and back buttons for moving within the history list.
2005-08-06 14:06:06 +02:00
set history {}
set historyindex 0
gitk: Make a row of controls for controlling highlighting Now there is a bar across the middle (just below the bar containing the sha1 ID, find string etc.) which controls highlighting. There are three ways to highlight: the user can highlight commits affecting a list of paths, commits in a view, or commits where the author or committer matches any of a list of strings (case-insensitive). The elements of the list of paths and list of names are delimited by whitespace with shell quoting rules. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 01:38:11 +02:00
set fh_serial 0
set nhl_names {}
gitk: Highlight entries in the file list as well This applies a bold highlight to entries in the file list pane in the bottom right corner when it is displaying the list of changed files. This doesn't yet highlight file list entries when it is in tree view mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-20 13:31:52 +02:00
set highlight_paths {}
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
set findpattern {}
gitk: Improve the text window search function This makes it work a bit more smoothly, and adds a reverse-search function, for which I stole the ^R binding from the find function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-25 13:25:13 +02:00
set searchdirn -forwards
gitk: Index line[hnd]tag arrays by id rather than row number This simplifies things a bit and is better because ids are stable but row numbers aren't. It also means we can avoid one [rowofcommit] call. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-11-13 13:01:46 +01:00
set boldids {}
set boldnameids {}
gitk: Allow user to choose whether to see the diff, old file, or new file This adds a set of radiobuttons that select between displaying the full diff (both - and + lines), the old file (suppressing the + lines) and the new file (suppressing the - lines) in the diff display window. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-04-19 03:39:12 +02:00
set diffelide {0 0}
gitk: Fix the find and highlight functions This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-04 11:43:51 +02:00
set markingmatches 0
gitk: Fix some problems with the display of ids as links First, this fixes the problem where a SHA1 id wouldn't be displayed as a link if it wasn't in the part of the graph that had been laid out at the time the details pane was filled in, even if that commit later became part of the graph. This arranges for us to turn the SHA1 id into a link when we get to that id in laying out the graph. Secondly, there was a problem where the cursor wouldn't always turn to a hand when over a link, because the areas for two links could overlap slightly. This fixes that by using a counter rather than always reverting to a counter when we leave the region of a link (which can happen just after we've entered a different link). Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-23 14:24:38 +02:00
set linkentercount 0
gitk: Do only the parts of the layout that are needed This changes layoutrows and optimize_rows to make it possible to lay out only a little bit more of the graph than is visible, rather than having to lay out the whole graph from top to bottom. To lay out some of the graph without starting at the top, we use the new make_idlist procedure for the first row, then lay it out proceeding downwards as before. Empty list elements in rowidlist are used to denote rows that haven't been laid out yet. Optimizing happens much as before except that we don't try to optimize unless we have three consecutive rows laid out (or the top 2 rows). We have a new list, rowisopt, to record which rows have been optimized. If we change a row that has already been drawn, we set a flag which causes drawcommits to throw away everything drawn on the canvas and redraw the visible rows. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-08-29 13:45:21 +02:00
set need_redisplay 0
set nrows_drawn 0
gitk: Fix the tab setting in the diff display window This fixes the bug where we were using the wrong font to calculate the width of the tab stops in the diff display window. If we're running on Tk 8.5 we also use the new -tabstyle wordprocessor option that makes tabs work as expected, i.e. a tab moves the cursor to the right until the next tab stop is reached. On Tk 8.5 we also get fancy and set the first tab stop at column 1 for a normal diff or column N for a merge diff with N parents. On Tk8.4 we can't do that because the tabs work in the "tabular" style, i.e. the nth tab character moves to the location of the nth tab position, *unless* you ask for the default tab setting, which gives 8-column tabs that work in the "wordprocessor" mode. So on Tk8.4 if the tab setting is 8 we ask for default tabs. This means that a tab setting of 7 or 9 can look quite different to 8 in some cases. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-28 13:27:39 +02:00
set firsttabstop 0
gitk: New improved gitk This is a new version of gitk which is much faster and has much better graph layout. It achieves the speed by only drawing the parts of the canvases that are actually visible. It also draws the commits in the order that git-rev-list produces them, so if you use -d, you need to have a recent enough git-rev-list that understands the --date-order flag. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-02-19 12:44:47 +01:00
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set nextviewnum 1
set curview 0
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
set selectedview 0
[PATCH] gitk i18n: More markup -- various options menus Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:44:35 +01:00
set selectedhlview [mc "None"]
set highlight_related [mc "None"]
gitk: Simplify highlighting interface and combine with Find function This effectively coaelesces the highlighting function and the search function. Instead of separate highlight and find controls, there is now one set of interface elements that controls both. The main selector is a drop-down menu that controls whether commits are highlighted and searched for on the basis of text in the commit (i.e. the commit object), files affected by the commit or strings added/removed by the commit. The functions to highlight by membership of a view or by ancestor/ descendent relation to the selected commit are gone, as is the move to next/previous highlighted commit (shift-up/down) function. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-09-22 04:49:33 +02:00
set highlight_files {}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set viewfiles(0) {}
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
set viewperm(0) 0
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
set viewargs(0) {}
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
set viewargscmd(0) {}
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
gitk: Fix bug where current row number display stops working The display of the current row number would stop working if the user clicked on a line, or if selectedline got unset for any other reason, because the trace on it got lost when it was unselected. This fixes it by changing the places that unset selectedline to set it to the empty string instead, and the places that tested for it being set or unset to compare it with the empty string. Thus it never gets unset now. This actually simplified the code in a few places since it can be compared for equality with a row number now without first testing if it is set. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-20 12:51:06 +02:00
set selectedline {}
gitk: Show current row number and total number of rows This adds a couple of fields in the bar just below the upper panes that show the row number of the currently selected commit, and how many rows are displayed in total. The latter increments as commits are read in, and thus functions to show that progress is being made. This therefore also removes the code that showed progress using a green oscillating bar in the progress bar window (which some people disliked). Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-05-11 14:13:02 +02:00
set numcommits 0
gitk: Use git log without --topo-order and reorganize the commits ourselves This very large patch implements code to organize the commits from git log into "arcs" (sequences of commits where each pair of adjacent commits are the only parent and child of each other), and orders the arcs so as to get a topological ordering of the commits. This means we can use git log without --topo-order and display the commits as we get them, incrementally, which makes the cold-cache start up time much faster, particularly on unpacked repos. One beneficial effect of this is that the File->Update menu item now just adds any new commits to the existing graph instead of rereading the whole thing from scratch, which is much faster. (If you do want to reread the whole graph from scratch you can use File->Reload.) At an implementation level, this means that the displayorder and parentlist lists are no longer fully valid at all times, and the commitrow array has gone. New procedures commitinview and commitonrow replace the commitrow array, and make_disporder ensures that displayorder and parentlist are valid for a range of rows. The overall time to load the kernel repository has gone up a bit, from ~9 seconds to ~11 seconds on my G5, but I think that is worth it given that the time to get a window up with commits displayed in it has gone from ~3 seconds to under 1 second. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-12-03 00:33:01 +01:00
set loginstance 0
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
set cmdlineok 0
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
set stopped 0
save window geometry on exit, and restore it on startup
2005-05-17 01:54:58 +02:00
set stuffsaved 0
Add a menu entry for generating a patch between any two commits.
2005-06-27 11:27:32 +02:00
set patchnum 0
gitk: Show local uncommitted changes as a fake commit If there are local changes in the repository, i.e., git-diff-index HEAD produces some output, then this optionally displays an extra row in the graph as a child of the HEAD commit (but with a red circle to indicate that it's not a real commit). There is a checkbox in the preferences window to control whether gitk does this or not. Clicking on the extra row shows the diffs between the working directory and the HEAD (using git diff-index -p). The right-click menu on the extra row allows the user to generate a patch containing the local diffs, or to display the diffs between the working directory and any commit. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-09-07 02:21:39 +02:00
set lserial 0
[PATCH] gitk: Don't show local changes when we there is no work tree Launching gitk on a bare repository or a .git directory would previously show the work tree as having removed all files. We now inhibit showing local changes when gitk is not launched from within a work tree. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-03-10 11:54:56 +01:00
set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
Made commit list reading asynchronous Added control+/- to increase/decrease font sizes Rearranged code a little.
2005-05-15 14:55:47 +02:00
setcoords
gitk: Make File->Update work properly again If a view is selected it will now just update that view. Also fixed a few other things - if you switch away from a view while gitk is still reading it in, then switch back, gitk will re-read it from scratch. We now re-read the references when switching views. If something was selected before a view change, and we need to read in the new view, we now select the previously-selected commit when we come across it. Fixed a bug in setting of rowrangelist plus a couple of other minor things. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-06 02:18:23 +02:00
makewindow
gitk: Provide a window icon if possible Try to set up a 16x16 Tk photo image (based on the git logo) and use it as window icon. The code is wrapped in a catch because it may fail in earlier Tcl/Tk 8.4 releases that don't provide 'wm iconphoto'. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-19 09:54:17 +01:00
catch {
image create photo gitlogo -width 16 -height 16
image create photo gitlogominus -width 4 -height 2
gitlogominus put #C00000 -to 0 0 4 2
gitlogo copy gitlogominus -to 1 5
gitlogo copy gitlogominus -to 6 5
gitlogo copy gitlogominus -to 11 5
image delete gitlogominus
image create photo gitlogoplus -width 4 -height 4
gitlogoplus put #008000 -to 1 0 3 4
gitlogoplus put #008000 -to 0 1 4 3
gitlogo copy gitlogoplus -to 1 9
gitlogo copy gitlogoplus -to 6 9
gitlogo copy gitlogoplus -to 11 9
image delete gitlogoplus
gitk: Provide a 32x32 window icon based on the git logo This simply expands the 16x16 logo image to 32x32 and provides it as an alternative icon image. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-19 09:54:18 +01:00
image create photo gitlogo32 -width 32 -height 32
gitlogo32 copy gitlogo -zoom 2 2
wm iconphoto . -default gitlogo gitlogo32
gitk: Provide a window icon if possible Try to set up a 16x16 Tk photo image (based on the git logo) and use it as window icon. The code is wrapped in a catch because it may fail in earlier Tcl/Tk 8.4 releases that don't provide 'wm iconphoto'. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-03-19 09:54:17 +01:00
}
gitk: Wait for the window to become visible after creating it When the git log process returned an error immediately, we were sometimes getting no main window and no error window displayed, with the gitk process just hanging waiting for something. It appears that the tkwait in show_error, which waits for the error window to be destroyed, wasn't sufficient to allow the main window or the error window to be mapped. This adds a wait in the main startup code after the main window has been created to wait until it is visible. This seems to fix the problem. Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-07-23 13:35:03 +02:00
# wait for the window to become visible
tkwait visibility .
[PATCH] gitk: add current directory to main window title This can help people keep track of which gitk is which, when they have several on the screen. Signed-off-by: Doug Maxey <dwm@enoyolf.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-12-10 21:31:46 +01:00
wm title . "[file tail $argv0]: [file tail [pwd]]"
gitk: Avoid crash if closed while reading references As recorded in msysGit issue 125, if the user closes gitk while it reports itself as still reading references then Tk will crash in the geometry management code. This has been fixed for Tk 8.5.7 and above. This patch avoids the problem by flushing outstanding geometry events before calling the readrefs procedure. See also http://code.google.com/p/msysgit/issues/detail?id=125 Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
2009-04-15 18:14:03 +02:00
update
Read tags from .git/refs/tags/* and mark commits with tags with a label. Allow SHA1 ids or tags to be entered in the SHA1 ID field.
2005-05-21 09:35:37 +02:00
readrefs
gitk: Use git-rev-parse only to identify file/dir names on cmd line This uses git-rev-parse --no-revs --no-flags to give us just the file and directory names on the command line, so that we can create the "Command line" view if any were specified. All other arguments just get passed to git-rev-list (without a pass through git-rev-parse). Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-23 14:45:55 +02:00
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
# create a view for the files/dirs specified on the command line
set curview 1
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
set selectedview 1
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set nextviewnum 2
[PATCH] gitk i18n: Markup several strings for translation This just marks up plain strings, that aren't used in any unusual way. Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
2007-11-07 18:42:55 +01:00
set viewname(1) [mc "Command line"]
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
set viewfiles(1) $cmdline_files
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
set viewargs(1) $revtreeargs
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
set viewargscmd(1) $revtreeargscmd
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
set viewperm(1) 0
gitk: Reorganize processing of arguments for git log This moves the scanning of the argument list for each view into a new function, parseviewargs, which is called from start_rev_list. This also makes the date mode and the merge mode be per-view rather than global. In merge mode, we work out the list of relevant files in a new function called from start_rev_list, so it will be updated on File->Reload. Plus we now do that after running the argscmd, so if we have one and it generates a -d or --merge option they will be correctly handled now. The other thing this does is to make errors detected in start_rev_list not be fatal. Now instead of doing exit 1 we just pop up and error window and put "No commits selected" in the graph pane. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-04-26 08:00:00 +02:00
set vdatemode(1) 0
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
addviewmenu 1
gitk: New way of constructing menus that allows for Alt+letter accelerators This is inspired by patches from Robin Rosenberg but takes a different approach. This adds a "makemenu" procedure for constructing menus that allows the menu layout to be specified in a clear fashion, and provides one place where the alt+letter accelerators can be detected and handled. The alt+letter accelerator is specified by putting an ampersand (&) before the letter for the accelerator in the menu item name. (Two ampersands in succession produce one ampersand in the menu item as it appears on screen.) This is handled in makemenu. We also add an mca procedure which is like mc but also does the ampersand translation, for use when we want to refer to a menu item by name. The mca name and the locations where we use it were shamelessly stolen from Robin Rosenberg's patch. This doesn't actually add any alt+letter accelerators yet. Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-10-17 13:44:42 +02:00
.bar.view entryconf [mca "Edit view..."] -state normal
.bar.view entryconf [mca "Delete view"] -state normal
gitk: Implement multiple views With this, gitk can know about the graphs for multiple sets of files and directories of interest. Each set of files/dirs and its graph is called a "view". There is always the "All files" view, which is the complete graph showing all commits. If files or dirs are specified on the command line, a "Command line" view is automatically created. Users can create new views and switch between them, and can delete any view except the "All files" view. This required a bit of reengineering. In particular, some more things that were arrays have now become lists. The idrowranges array is still used while the graph is being laid out, but for rows that have been laid out we use the rowrangelist list instead. The cornercrossings and crossings arrays no longer exist, and instead we compute the crossings when needed (in assigncolor). Still to be done: make the back/forward buttons switch views as necessary; make the updatecommits function work right; preserve the selection if possible when the new view has to be read in; fix the case when the user switches away from the current view while we are still reading it in and laying it out; further optimizations. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-04 02:16:22 +02:00
}
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
if {[info exists permviews]} {
foreach v $permviews {
set n $nextviewnum
incr nextviewnum
set viewname($n) [lindex $v 0]
set viewfiles($n) [lindex $v 1]
gitk: Allow view to specify arbitrary arguments to git-rev-list The list of arguments to git-rev-list, including arguments that select the range of commits, is now a part of the view specification. If any arguments are given to gitk, they become part of the "Command line" view, and the non-file arguments become the default for any new views created. Getting an error from git-rev-list is no longer fatal; instead the error window pops up, and when you press OK, the main window just shows "No commits selected". The git-rev-list arguments are entered in an entry widget in the view editor window using shell quoting conventions, not Tcl quoting conventions. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-03 01:32:53 +02:00
set viewargs($n) [lindex $v 2]
[PATCH] Add an --argscmd flag to get the list of refs to show This allows gitk to be used to display a different set of refs each the display is refreshed. This is useful when gitk is called from other porcelain suites, for doing such things as displaying the set of patches in a patch stack. The user specifies a command as the argument to the --argscmd option. The command is run initially and each time the display is refreshed, and is expected to generate a list of commit IDs, one per line. Those commits are appended to the commits passed on the command-line when constructing the git log command to be executed. The command is considered to be an attribute of a view, and has its own field in the saved view, and an edit field in the view editor. Signed-off-by: Yann Dirson <ydirson@altern.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-02-21 21:23:31 +01:00
set viewargscmd($n) [lindex $v 3]
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
set viewperm($n) 1
gitk: Basic support for highlighting one view within another With this, one view can be used as a highlight for another, so that the commits that are in the highlight view are displayed in bold. This required some fairly major changes to how the list of ids, parents, children, and id to row mapping were stored for each view. We can now be reading in several views at once; for all except the current view, we just update the displayorder and the lists of parents and children for the view. This also creates a little bit of infrastructure for handling the watch cursor. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-05-02 03:15:29 +02:00
addviewmenu $n
gitk: Implement "permanent" views (stored in ~/.gitk) With this the user can now mark a view as "permanent" and it will appear in the list every time gitk is started (until it is deleted). Also tidied up the view definition window, and changed the view menu to use radiobuttons for the view selections so there is some feedback as to which is the current view. Signed-off-by: Paul Mackerras <paulus@samba.org>
2006-04-25 09:12:46 +02:00
}
}
gitk: Force the focus to the main window on Windows On msysGit, the focus is first on the (Tk) console. This console is then hidden, but keeps the focus. Work around that by forcing the focus onto the gitk window. This fixes msysGit issue 14. Diagnosed and originally fixed by Johannes Schindelin. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-18 08:30:49 +01:00
if {[tk windowingsystem] eq "win32"} {
focus -force .
}
gitk: Fixed automatic row selection during load - Switching views now actually preserves the selected commit. - Reloading (also Edit View) preserves the currently selected commit. - Initial selection does not produce weird scrolling. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-07-26 18:13:45 +02:00
getcommits {}
Reference in New Issue Copy Permalink