![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
gitk: Bind Key-Return to create on new branch dialog
The Return key can now be used as well as pressing the Create button
from the dialog box that is shown when selecting "Create new branch".
Signed-off-by: Richard Quirk <richard.quirk@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The Return key can now be used as well as pressing the Create button
from the dialog box that is shown when selecting "Create new branch".
Signed-off-by: Richard Quirk <richard.quirk@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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>
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>
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>
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>
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>
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>
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>
gitk: Add untranslated error messages to translation
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
gitk: Update swedish translation.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Updated German translation
This includes suggestions by Stephan Beyer.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This includes suggestions by Stephan Beyer.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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>
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
gitk: Fix bug introduced by "gitk: Fix "wrong # coordinates" error on reload"
Commit 94503a66c56c935e77a8fbe3622f1f56b7134ccc ("gitk: Fix "wrong #
coordinates" error on reload") was correct as far as it went, but
introduced a problem because it didn't also clear out boldrows and
boldnamerows in clear_display. This resulted in Tcl errors after
scrolling through the graph for a while if some rows were highlighted.
This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Commit 94503a66c56c935e77a8fbe3622f1f56b7134ccc ("gitk: Fix "wrong #
coordinates" error on reload") was correct as far as it went, but
introduced a problem because it didn't also clear out boldrows and
boldnamerows in clear_display. This resulted in Tcl errors after
scrolling through the graph for a while if some rows were highlighted.
This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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>
gitk: Move es.po where it belongs
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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>
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>
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>
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>
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>
Merge branch 'master' into dev
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>
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>
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>
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>
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>
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>
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>
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>
gitk: German translation again updated
This includes suggestions by Stephan Beyer.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This includes suggestions by Stephan Beyer.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Update German translation
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Makefile/install: force permissions when installing files and dirs
The msg-files msgs/*.msg used to be installed with mode 755 although
they're not executables. With this commit, files are forced to be
installed with mode 644, directories and executables with mode 755.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The msg-files msgs/*.msg used to be installed with mode 755 although
they're not executables. With this commit, files are forced to be
installed with mode 644, directories and executables with mode 755.
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Initial Swedish translation.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Spanish translation of gitk
I copied the Italian translation and translated the strings
to Spanish starting from there. This incorporates suggestions
from Wincent Colaiuta and Carlos Rica.
Signed-off-by: Santiago Gala <sgala@apache.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
I copied the Italian translation and translated the strings
to Spanish starting from there. This incorporates suggestions
from Wincent Colaiuta and Carlos Rica.
Signed-off-by: Santiago Gala <sgala@apache.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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>
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>
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>
gitk: Fix changing colors through Edit->Preferences
With tcl/tk8.5 the lset command seems to behave differently. When
changing the background color through Edit->Preferences, the changes
are applied, but new dialogs, such as View->New view... barf with
Error: unknown color name "{#ffffff}"
Additionally when closing gitk, and starting it up again, a bad value
has been saved to ~/.gitk, preventing gitk from running properly; it
fails with
Error in startup script: unknown color name "{#ffffff}"
...
This commit fixes the problem by changing the color dialogs to pass
the empty string {} as the list index to choosecolor. This causes
the lset and lindex commands used by choosecolor to use and set the
whole variable (bgcolor, fgcolor or selectbgcolor) rather than
treating them as a 1-element list. Tested with tcl/tk8.4 and 8.5.
Dmitry Potapov reported this problem through
http://bugs.debian.org/472615
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
With tcl/tk8.5 the lset command seems to behave differently. When
changing the background color through Edit->Preferences, the changes
are applied, but new dialogs, such as View->New view... barf with
Error: unknown color name "{#ffffff}"
Additionally when closing gitk, and starting it up again, a bad value
has been saved to ~/.gitk, preventing gitk from running properly; it
fails with
Error in startup script: unknown color name "{#ffffff}"
...
This commit fixes the problem by changing the color dialogs to pass
the empty string {} as the list index to choosecolor. This causes
the lset and lindex commands used by choosecolor to use and set the
whole variable (bgcolor, fgcolor or selectbgcolor) rather than
treating them as a 1-element list. Tested with tcl/tk8.4 and 8.5.
Dmitry Potapov reported this problem through
http://bugs.debian.org/472615
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: initial Italian translation
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Default to using po2msg.sh if msgfmt doesn't grok --tcl, -l and -d
This is a similar change to that submitted by Junio C Hamano for
git-gui. It tests whether the msgfmt command can be run successfully
with --tcl, -l and -d, and if not, falls back to using po/po2msg.sh.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is a similar change to that submitted by Junio C Hamano for
git-gui. It tests whether the msgfmt command can be run successfully
with --tcl, -l and -d, and if not, falls back to using po/po2msg.sh.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge branch 'master' into dev
gitk: Avoid Tcl error when switching views
Michele Ballabio <barra_cuda@katamail.com> pointed out that gitk
sometimes throws a Tcl error (can't read "yscreen") when switching
views, and proposed a patch. This is a different way of fixing it
which is a bit neater. Basically, in showview we only set yscreen if
the selected commit is on screen to start with, and then we only
scroll the canvas to bring it onscreen if yscreen is set and the
same commit exists in the new view.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Michele Ballabio <barra_cuda@katamail.com> pointed out that gitk
sometimes throws a Tcl error (can't read "yscreen") when switching
views, and proposed a patch. This is a different way of fixing it
which is a bit neater. Basically, in showview we only set yscreen if
the selected commit is on screen to start with, and then we only
scroll the canvas to bring it onscreen if yscreen is set and the
same commit exists in the new view.
Signed-off-by: Paul Mackerras <paulus@samba.org>
[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>
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>
[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>
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>
[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>
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>
[PATCH] gitk: Mark another string for translation
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
[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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
... 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>
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>
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>
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>
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>
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>
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>
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>
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>
Merge branch 'master' into dev
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>
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>
[PATCH] gitk: Heed the lines of context in merge commits
There is an edit box where the number of context lines can be chosen.
But it was only used when regular diffs were displayed, not for
merge commits. This fixes it.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Paul Mackerras <paulus@samba.org>
There is an edit box where the number of context lines can be chosen.
But it was only used when regular diffs were displayed, not for
merge commits. This fixes it.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Paul Mackerras <paulus@samba.org>
[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>
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>
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>
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>
[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>
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>
[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>
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>
[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>
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>
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>
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>
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>
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>
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>
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>
[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>
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>
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>
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>
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>
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>
gitk: Update German translation.
Now 100% complete (163 strings).
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now 100% complete (163 strings).
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Fix typo in user message.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Fix the Makefile to cope with systems lacking msgfmt
The po2msg.sh script and the .gitignore in the po directory have been
shamelessly copied from the current git-gui. This enables the top
level "make NO_MSGFMT" to work consistently for git across the git-gui
and gitk sub-projects.
This is the same effective patch that has previously been posted as a
git.git patch which more succinctly described the copying of
po/.gitignore and po/po2msg.sh from git-gui.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The po2msg.sh script and the .gitignore in the po directory have been
shamelessly copied from the current git-gui. This enables the top
level "make NO_MSGFMT" to work consistently for git across the git-gui
and gitk sub-projects.
This is the same effective patch that has previously been posted as a
git.git patch which more succinctly described the copying of
po/.gitignore and po/po2msg.sh from git-gui.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Fix handling of flag arguments
Despite the name, the --revs-only flag to git rev-parse doesn't make
it output only revision IDs. It makes it output only arguments that
are suitable for giving to git rev-list. So make start_rev_list and
updatecommits cope with arguments output by git rev-parse that aren't
revision IDs. This way we won't get an error when an argument such as
"-300" has been given to gitk and the view is updated.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Despite the name, the --revs-only flag to git rev-parse doesn't make
it output only revision IDs. It makes it output only arguments that
are suitable for giving to git rev-list. So make start_rev_list and
updatecommits cope with arguments output by git rev-parse that aren't
revision IDs. This way we won't get an error when an argument such as
"-300" has been given to gitk and the view is updated.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Merge branch 'master' into dev
[PATCH] gitk: use user-configured background in view definition dialog
Have the text fields in the view definition dialog (View->New view...)
use the background color as configured through the preferences, instead
of hard-coded 'white'.
This was suggested by Paul Wise through http://bugs.debian.org/457124
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Have the text fields in the view definition dialog (View->New view...)
use the background color as configured through the preferences, instead
of hard-coded 'white'.
This was suggested by Paul Wise through http://bugs.debian.org/457124
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
[PATCH] gitk: Update German translation
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
[PATCH] gitk: Update and fix Makefile
This Makefile uses the template provided at git.git/gitk-git/Makefile
by Junio and adds the rules for the i18n files.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This Makefile uses the template provided at git.git/gitk-git/Makefile
by Junio and adds the rules for the i18n files.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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>
Merge branch 'master' into dev
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>
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>
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>
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>
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>
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>
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>
* 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>
Merge branch 'master' into dev
gitk: Recode de.po to UTF-8
Somehow de.po got recoded to latin-1 in the process of committing it.
This recodes it back to UTF-8.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Somehow de.po got recoded to latin-1 in the process of committing it.
This recodes it back to UTF-8.
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
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>
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>
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>
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>
* 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>
Merge branch 'master' into dev
16 years ago[PATCH] gitk i18n: Recode gitk from latin1 to utf8 so that the (c) copyright characte...
[PATCH] gitk i18n: Recode gitk from latin1 to utf8 so that the (c) copyright character is valid utf8.
When using translations, the target language must be encoded in utf-8
because almost all target languages will contain non-ascii characters.
For that reason, the non-translated strings should be in utf-8 as well
so that there isn't any encoding mixup inside the program.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When using translations, the target language must be encoded in utf-8
because almost all target languages will contain non-ascii characters.
For that reason, the non-translated strings should be in utf-8 as well
so that there isn't any encoding mixup inside the program.
Signed-off-by: Paul Mackerras <paulus@samba.org>