Auto-select ("Copy commit ID to X11 selection") is useful when a
selection cliboard exists, but otherwise generally meaningless, for
instance on Windows.
Add a similar pref and behavior which copies the commit ID to the
primary clipboard - for platforms without a selection clipboard, but
which can also be useful additionally on platforms with selection.
Note that while autoselect is enabled by default, autocopy isn't.
That's because the selection clipboard is typically dispensable, while
the primary clipboard can be considered a more precious resource,
which we don't want to (clear and) overwrite by default.
Signed-off-by: Avi Halachmi (:avih) <avihpit@yahoo.com>
Tl;DR: change Auto-select text, move the length input to a new line.
The Auto-select preference auto-selects [part of] the commit ID text
at the respective widget on startup, and when the current commit at
the graph changes.
Its real premise, however, is to populate the selection clipboard
with the commit ID. Consider, for instance, how meaningless it is on
platforms without a selection clipboard - like Windows or macOS (on
Windows the selection is not even visible with the default Tk theme,
because it's only visible in focused widgets - which the commit ID
widget is not during normal application of this selection).
So rename the Auto-select label to "Copy commit ID to X11 selection",
to reflect better the ultimate outcome of its application
Note that there exists other, non-X11 platforms with a selection
clipboard, like Wayland, and if a native Tk client exists on such
platforms, then the description will not be accurate, but hopefully
it's not too misleading either.
Additionally, move the length input widget to a new line, because:
- This length applies to both Auto-select and "Copy commit reference"
context menu item, so it's not exclusive to the selection length.
- The next commit will add support for primary clipboard as well,
where this length will also be used.
Also, move the "Hide remotes" item above these selection prefs, to
keep the selection prefs semi-grouped before the spacing of the
following title "Diff display options".
Signed-off-by: Avi Halachmi (:avih) <avihpit@yahoo.com>
SHA1 might not stay forever, and plans to use SHA256 already exist,
so use the official name for it - "Commit ID".
Only visible UI texts are modified to reduce the noise when using
git-blame, while comments and variable names still contain SHA1/sha1.
Signed-off-by: Avi Halachmi (:avih) <avihpit@yahoo.com>
In GNU Make commit 07fcee35 ([SV 64815] Recipe lines cannot contain
conditional statements, 2023-05-22) and following, conditional
statements may no longer be preceded by a tab character (which Make
refers to as the recipe prefix).
There are a handful of spots in our various Makefile(s) which will break
in a future release of Make containing 07fcee35. For instance, trying to
compile the pre-image of this patch with the tip of make.git results in
the following:
$ make -v | head -1 && make
GNU Make 4.4.90
config.mak.uname:842: *** missing 'endif'. Stop.
The kernel addressed this issue in 82175d1f9430 (kbuild: Replace tabs
with spaces when followed by conditionals, 2024-01-28). Address the
issues in Git's tree by applying the same strategy.
When a conditional word (ifeq, ifneq, ifdef, etc.) is preceded by one or
more tab characters, replace each tab character with 8 space characters
with the following:
find . -type f -not -path './.git/*' -name Makefile -or -name '*.mak' |
xargs perl -i -pe '
s/(\t+)(ifn?eq|ifn?def|else|endif)/" " x (length($1) * 8) . $2/ge unless /\\$/
'
The "unless /\\$/" removes any false-positives (like "\telse \"
appearing within a shell script as part of a recipe).
After doing so, Git compiles on newer versions of Make:
$ make -v | head -1 && make
GNU Make 4.4.90
GIT_VERSION = 2.44.0.414.gfac1dc44ca9
[...]
$ echo $?
0
Reported-by: Dario Gjorgjevski <dario.gjorgjevski@gmail.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cherry-picked-from: 728b9ac0c3
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
These sites offer https versions of their content.
Using the https versions provides some protection for users.
Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cherry-picked-from: d05b08cd52
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
It's somewhat traditional to respect sites' self-identification.
Signed-off-by: Josh Soref <jsoref@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cherry-picked-from: 65175d9ea2
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
We just started piping the file paths via `stdin` instead of passing
them via the command-line, to avoid running into command-line
limitations.
However, since we now pipe the file paths, we need to take care of
special characters.
This fixes https://github.com/git-for-windows/git/issues/2293
Signed-off-by: Nico Rieck <nico.rieck@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To avoid running into command line limitations, some of Git's commands
support the `--stdin` option.
Let's use exactly this option in the three rev-list/log invocations in
gitk that would otherwise possibly run the danger of trying to invoke a
too-long command line.
While it is easy to redirect either stdin or stdout in Tcl/Tk scripts,
what we need here is both. We need to capture the output, yet we also
need to pipe in the revs/files arguments via stdin (because stdin does
not have any limit, unlike the command line). To help this, we use the
neat Tcl feature where you can capture stdout and at the same time feed
a fixed string as stdin to the spawned process.
One non-obvious aspect about this change is that the `--stdin` option
allows to specify revs, the double-dash, and files, but *no* other
options such as `--not`. This is addressed by prefixing the "negative"
revs with `^` explicitly rather than relying on the `--not` option
(thanks for coming up with that idea, Max!).
This fixes https://github.com/git-for-windows/git/issues/1987
Analysis-and-initial-patch-by: Max Kirillov <max@max630.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6cd80496e9 ("gitk: Resize panes correctly when reducing window size",
2020-10-03) introduces a mechanism to record previously-set sash
positions to make sure that correct values are used while computing
resize proportions. However, if we are not using ttk, then sash
represents only the x coordinate and the recorded sash (`oldsash`) only
includes the x coordinate. When we need to access the y coordinate via
the recorded sash position, we generate the following Application Error
popup:
Error: expected integer but got ""
expected integer but got ""
expected integer but got ""
while executing
"$win sash place 0 $sash0 [lindex $s0 1]"
(procedure "resizeclistpanes" line 38)
invoked from within
"resizeclistpanes .tf.histframe.pwclist 2818"
(command bound to event)
To fix this, if we are not using ttk, we append the sash positions with
the y coordinates before recording them to match the use_ttk case.
Signed-off-by: Halil Sen <halil.sen@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The resizeclistpanes and resizecdetpanes procedures attempt to keep
the horizontal proportions of the panes of the gitk window
approximately constant when the gitk window is resized. However, if
the size is reduced enough that an existing sash position would go
outside the window, Tk moves the sash to the left to keep it inside
the window (without moving other sash positions to keep the
proportions). This happens before these resize procedures get
control, and so they work with incorrect proportions.
To fix this, we record the sash positions we set previously and use
those previously-set sash positions rather than the current sash
positions when computing the proportions.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The source code is a mix of tabs and spaces. The indentation style
currently is four spaces per indent level but uses tabs every other
level (at eight spaces). Fix this inconsistent spacing and tabbing by
just using a space-indent for everything.
This was done mechanically by running:
$ expand -i gitk >gitk.new
$ mv gitk.new gitk
This patch should be empty with `--ignore-all-space`.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Currently, submodule diffs can cause the diff context menu to fail
to appear because of a couple bugs in parseblobdiffline:
* it appends the submodule name to ctext_file_lines instead of
a line number, which breaks the binary search in find_ctext_fileinfo;
* it can desynchronize ctext_file_names and ctext_file_lines
by appending to the former but not the latter, which also breaks
find_ctext_fileinfo.
Fix both of these.
Note: a side effect of this patch is that the context menu also
starts appearing when you right-click on submodule diffs (and not just
regular diffs). The menu is non-functional in this case, though,
since you can't run blame on submodules.
Signed-off-by: Роман Донченко <dpb@corrigendum.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The recently introduced background for the tags that highlight
added and removed text takes precedence over the background color
of the selection. But selected text is more important than the
highlighted text. Make the highlighting tags the lowest priority.
The same argument holds for the file separator and the highlight
of search results. Therefore, make them also low-priority. But
search results are a bit more important; therefore, keep them
above the other tags.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Not using colored background for added and removed lines is a missed
opportunity to make diff lines easier to grasp visually.
Use a subtle red/green background by default. Make the font slightly darker
to improve contrast.
Signed-off-by: Stefan Dotterweich <stefandotterweich@gmx.de>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
784b7e2f ("gitk: Fix "External diff" with separate work tree",
2011-04-04) added an unconditional call to "git rev-parse
--show-toplevel" to set up a global variable quite early in the
course of the program, so that the location of the working tree can
later be known if/when the user chooses to run the external diff via
the external_diff_get_one_file proc. Before that change, the
external diff code used to assume that the parent directory of ".git"
directory is the top-level of the working tree.
Recent versions of git however notices that "rev-parse --show-toplevel"
executed in a bare repository is an error, which makes gitk stop,
even before the user could attempt to run external diff.
Use the gitworktree helper introduced in 65bb0bda ("gitk: Fix the
display of files when filtered by path", 2011-12-13), which is
prepared to see failures from "rev-parse --show-toplevel" and other
means it tries to find the top-level of the working tree instead to
work around this issue. The resulting value in $worktree global,
when run in a bare repository, is bogus, but the code is not
prepared to run external diff correctly without a working tree
anyway ;-)
[paulus@ozlabs.org - folded in fix from Eric Sunshine]
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Bug was: gitk would overwrite the botwidth setting in .gitk with
a nonsense value when not using tk themes. Moving the affected
line within the conditional results in the expected behavior.
Signed-off-by: Eric Huber <echuber2@illinois.edu>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
gitk applies submodule highlighting (coloring lines starting with
" >" and " <") when `currdiffsubmod` is not an empty string.
However, it fails to reset `currdiffsubmod` after a submodule diff
ends, so any file diffs following a submodule diff will still be
highlighted as if they were submodule diffs.
There are two problems with the way gitk tries to reset `currdiffsubmod`:
1. The code says `set $currdiffsubmod` instead of `set currdiffsubmod`,
so it actually sets the variable whose name is the submodule path
instead.
2. It tries to do it after the first line in a submodule diff, which
is incorrect, since submodule diffs can contain multiple lines.
Fix this by resetting `currdiffsubmod` when a file diff starts.
Signed-off-by: Роман Донченко <dpb@corrigendum.ru>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
After "git checkout -b '漢字'" to create a branch with UTF-8
character in it, "gitk" shows the branch name incorrectly, as it
forgets to turn the bytes read from the "git show-ref" command
into Unicode characters.
Signed-off-by: Kazuhiro Kato <kato-k@ksysllc.co.jp>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Now that the commit reference format has a canonical name, let's use this
name in gitk's UI and implementation.
Signed-off-by: Beat Bolli <dev+git@drbeat.li>
[dl: based the patch on gitk's tree]
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
When running make from a clean environment, all of the *.po files should
be converted into *.msg files. After that, when make is run without any
changes, make should not do anything.
After beffae768a (gitk: Add Chinese (zh_CN) translation, 2017-03-11),
zh_CN.po was introduced. When make was run, a zh_cn.msg file was
generated (notice the lowercase). However, since make is case-sensitive,
it expects zh_CN.po to generate a zh_CN.msg file so make will keep
reattempting to generate a zh_CN.msg so successive make invocations
result in
Generating catalog po/zh_cn.msg
msgfmt --statistics --tcl po/zh_cn.po -l zh_cn -d po/
317 translated messages.
happening continuously.
Rename zh_CN.po to zh_cn.po so that when make generates the zh_cn.msg
file, it will realize that it was successfully generated and only run
once.
Signed-off-by: Denton Liu <liu.denton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unchanged lines are prefixed with a white-space, thus unchanged lines
starting with either " <" or " >" are mistaken for submodule changes.
Check if a line starts with either " <" or " >" only if we are listing
the changes of a submodule.
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Makes it easier to see which refs are local and which refs are remote.
Adds consistency with the remote background colour in the graph display.
Signed-off-by: Paul Wise <pabs3@bonedaddy.net>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
This makes gitk look for http or https URLs in the commit description
and make the URLs clickable. Clicking on them will invoke an external
web browser with the URL.
The web browser command is by default "xdg-open" on Linux, "open" on
MacOS, and "cmd /c start" on Windows. The command can be changed in
the preferences window, and it can include parameters as well as the
command name. If it is set to the empty string then URLs will no
longer be made clickable.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
"make update-po" fails because a previously untranslated string
has now been translated:
Updating po/sv.po
po/sv.po:1388: duplicate message definition...
po/sv.po:380: ...this is the location of the first definition
Remove the duplicate message definition.
Reported-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
After a reload we might have an entirely different set of commits,
so keeping all of them leaks memory. Remove them all because
re-creating them is not more expensive than testing wether they're
still valid. Lazy (re-)creation is already well established, so
a missing entry can't cause harm.
Signed-off-by: Markus Hitter <mah@jump-ing.de>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
One shouldn't have descriptors of already closed files around.
The first idea to deal with this (previously) ever growing array
was to remove it entirely, but it's needed to detect start of a
new diff with ths old diff not yet done. This happens when a user
clicks on the same commit in the commit list repeatedly without
delay.
Signed-off-by: Markus Hitter <mah@jump-ing.de>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
The diff text widget is read-only, so there's zero point in
building an undo stack. This change reduces memory consumption of
this widget by about 95%.
Memory usage of the whole program for viewing a reference commit
before; 579'692'744 bytes, after: 32'724'446 bytes.
Test procedure:
- Choose a largish commit and check it out. In this case one with
90'802 lines, 5'006'902 bytes.
- Have a Tcl version with memory debugging enabled. This is,
build one with --enable-symbols=mem passed to configure.
- Instrument Gitk to regularly show a memory dump. E.g. by adding
these code lines at the very bottom:
proc memDump {} {
catch {
set output [memory info]
puts $output
}
after 3000 memDump
}
memDump
- Start Gitk, it'll load this largish commit into the diff text
field automatically (because it's the current commit).
- Wait until memory consumption levels out and note the numbers.
Note that the numbers reported by [memory info] are much smaller
than the ones reported in 'top' (1.75 GB vs. 105 MB in this case),
likely due to all the instrumentation coming with the debug
version of Tcl.
Signed-off-by: Markus Hitter <mah@jump-ing.de>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
When -S or -G is used as a filter option, the resulting commit list
rarely contains all matching commits. Only a certain number of commits
are displayed and the rest are missing.
"git log --boundary -S" does not return as many boundary commits as you
might expect. gitk makes up for this in closevarcs() by adding missing
parent (boundary) commits. However, it does not change $numcommits,
which limits how many commits are shown. In the end, some commits at the
end of the commit list are simply not shown.
Change $numcommits whenever a missing parent is added to the current
view.
Signed-off-by: Stefan Dotterweich <stefandotterweich@gmx.de>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Some systems don't recognize "lime" as a color, leading to errors when
gitk is run. What we want is a bright green, so use "#00ff00" instead.
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Force creation of destination bin directory. Without this, gitk
would fail to install if this directory didn't already exist.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Hi,
I made another branch dialog related change, included in this message.
It applies on top of my other two patches.
Rogier.
------- 8< ------------------- 8< --------------
Only the SHA1 was included. It's convenient to have the title
mentioned as well.
Signed-off-by: Rogier Goossens <goossens.rogier@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Git allows checking out remote branches, creating a local tracking
branch in the process. Allow gitk to do this as well, provided a
local branch of the same name does not yet exist.
Signed-off-by: Rogier Goossens <goossens.rogier@gmail.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Make Help > About & Key bindings dialogs readable if theme
has changed font color to something incompatible with white.
Signed-off-by: Guillermo S. Romero <gsromero@infernal-iceberg.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
