gitk: Add keybinding to switch to parent commit

Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Updated Bulgarian translation (302t,0f,0u)

Signed-off-by: Alexander Shopov <ash@kambanaria.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Do not depend on Cygwin's "kill" command on Windows

Windows does not necessarily mean Cygwin, it could also be MSYS. The
latter ships with a version of "kill" that does not understand "-f".
In msysgit this was addressed by shipping Cygwin's version of kill.

Properly fix this by using the stock Windows "taskkill" command instead,
which is available since Windows XP Professional.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Show detached HEAD if --all is specified

If HEAD is detached, 'gitk --all' does not show it. This is inconvenient
for frontend program, and for example git log does show the detached HEAD.

gitk uses git rev-parse to find a list of branches to show.
Apparently, the command does not include detached HEAD to output if
--all argument is specified. This has been discussed in [1] and stated
as expected behavior. So rev-parse's parameters should be tuned in gitk.

[1] http://thread.gmane.org/gmane.comp.version-control.git/255996

Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Remove boilerplate for configuration variables

Signed-off-by: Max Kirillov <max@max630.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: write only changed configuration variables

When gitk contains some changed parameter, and there is existing
instance of gitk where the parameter is still old, it is reverted to
that old value when the instance exits.

Instead, store a parameter in config only it is has been modified in the
exiting instance. Otherwise, preserve the value which currently is in
file.  This allows editing the configuration when several instances are
running, and don't get rollback of the modification if some other
instance where the configuration was not edited is closed last.

Since trace(3tcl) can send bogus events, doublecheck if the value has
really been changed, but once it is marked as changed, do not reset it
back to unchanged ever, because if user has restored the original value,
it's the decision which should be stored as well as modified value.

Treat view list especially: instead of rewriting the whole list, merge
individual views. Place old and updated views at their older placed, add
new ones to the end of list.

Do not merge geometry values. They are almost always changing because
user moves and resises windows, and there is no way to find which one of
the geometries is most desired. Just overwrite them unconditionally,
like earlier.
gitk: cleanup tracing array elements for views
FIXUP: proper exists
gitk: synchronize config write

If several gitk instances are closed simultaneously, safestuff procedure
can run at the same time, resulting in a conflict which may cause losing
of some of the instance's changes, failing the saving operation or even
corrupting the configuration file. This can happen, for example, at user
session closing, or at group closing of all instances of an application
which is possible in some desktop environments.

To avoid this, make sure that only one saving operation is in progress.
It is guarded by existance of $config_file_tmp file. Both creating the
file and moving it to $config_file are atomic operations, so it should
be reliable.

Reading does not need to be syncronized, because moving is atomic
operation, and the $config_file always refers to full and correct file.
But, if there is a stale $config_file_tmp file, report it at gitk start.
If such file is detected at saving, just abort the saving, because this
is how gitk used to handle errors while saving.
gitk: use explicitly set flag viewchanged instead of traced variable
gitk_incremental_config_write: rebase to newer master

'gitk: Remove boilerplate for configuration variables' is accepted now
gitk: cleanup tracing array elements for views
gitk: synchronize config write

If several gitk instances are closed simultaneously, safestuff procedure
can run at the same time, resulting in a conflict which may cause losing
of some of the instance's changes, failing the saving operation or even
corrupting the configuration file. This can happen, for example, at user
session closing, or at group closing of all instances of an application
which is possible in some desktop environments.

To avoid this, make sure that only one saving operation is in progress.
It is guarded by existance of $config_file_tmp file. Both creating the
file and moving it to $config_file are atomic operations, so it should
be reliable.

Reading does not need to be syncronized, because moving is atomic
operation, and the $config_file always refers to full and correct file.
But, if there is a stale $config_file_tmp file, report it at gitk start.
If such file is detected at saving, just abort the saving, because this
is how gitk used to handle errors while saving.
gitk_incremental_config_write: proper rebase

Fix placing of config_check_tmp_exists{}
gitk: write only changed configuration variables

When gitk contains some changed parameter, and there is existing
instance of gitk where the parameter is still old, it is reverted to
that old value when the instance exits.

Instead, store a parameter in config only it is has been modified in the
exiting instance. Otherwise, preserve the value which currently is in
file.  This allows editing the configuration when several instances are
running, and don't get rollback of the modification if some other
instance where the configuration was not edited is closed last.

For scalar variables, use trace(3tcl) to detect their change. Since `trace` can
send bogus events, doublecheck if the value has really been changed, but once
it is marked as changed, do not reset it back to unchanged ever, because if
user has restored the original value, it's the decision which should be stored
as well as modified value.

Treat view list especially: instead of rewriting the whole list, merge
individual views. Place old and updated views at their older placed, add
new ones to the end of list. Collect modified view explicitly, in newviewok{}.

Do not merge geometry values. They are almost always changing because
user moves and resises windows, and there is no way to find which one of
the geometries is most desired. Just overwrite them unconditionally,
like earlier.
gitk: synchronize config write

If several gitk instances are closed simultaneously, safestuff procedure
can run at the same time, resulting in a conflict which may cause losing
of some of the instance's changes, failing the saving operation or even
corrupting the configuration file. This can happen, for example, at user
session closing, or at group closing of all instances of an application
which is possible in some desktop environments.

To avoid this, make sure that only one saving operation is in progress.
It is guarded by existance of $config_file_tmp file. Both creating the
file and moving it to $config_file are atomic operations, so it should
be reliable.

Reading does not need to be syncronized, because moving is atomic
operation, and the $config_file always refers to full and correct file.
But, if there is a stale $config_file_tmp file, report it at gitk start.
If such file is detected at saving, just abort the saving, because this
is how gitk used to handle errors while saving.
gitk_incremental_config_write: v3

* use explicit setting of changed view flag instead of array trace
* fix exists check