aboutsummaryrefslogtreecommitdiffstats
path: root/net/unix/af_unix.c
diff options
context:
space:
mode:
Diffstat (limited to 'net/unix/af_unix.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-20 22:29:11 +0000
ct the scrip that "builds" Gitk from our Makefile so that we can reuse it in Meson. Signed-off-by: Patrick Steinhardt <ps@pks.im> 2025-01-11gitk: make the "list references" default window width widerJames J. Raden1-1/+1 When using remotes (with git-flow especially), the remote reference names are almost always wordwrapped in the "list references" window because it's somewhat narrow by default. It's possible to resize it with a mouse, but it's annoying to have to do this every time, especially on Windows 10, where the window border seems to be only one (1) pixel wide, thus making the grabbing of the window border tricky. Signed-off-by: James J. Raden <james.raden@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 2025-01-11gitk: fix arrow keys in input fields with Tcl/Tk >= 8.6Johannes Schindelin1-3/+9 Tcl/Tk 8.6 introduced new events for the cursor left/right keys and apparently changed the behavior of the previous event. Let's work around that by using the new events when we are running with Tcl/Tk 8.6 or later. This fixes https://github.com/git-for-windows/git/issues/495 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 2025-01-11gitk: Use an external icon file on WindowsSebastian Schuberth1-23/+26 Git for Windows now ships with the new Git icon from git-scm.com. Use that icon file if it exists instead of the old procedurally drawn one. This patch was sent upstream but so far no decision on its inclusion was made, so commit it to our fork. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 2025-01-11gitk: Unicode file name supportKarsten Blees1-7/+8 Assumes file names in git tree objects are UTF-8 encoded. On most unix systems, the system encoding (and thus the TCL system encoding) will be UTF-8, so file names will be displayed correctly. On Windows, it is impossible to set the system encoding to UTF-8. Changing the TCL system encoding (via 'encoding system ...', e.g. in the startup code) is explicitly discouraged by the TCL docs. Change gitk functions dealing with file names to always convert from and to UTF-8. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 2025-01-11gitk(Windows): avoid inadvertently calling executables in the worktreeJohannes Schindelin1-0/+135 Just like CVE-2022-41953 for Git GUI, there exists a vulnerability of `gitk` where it looks for `taskkill.exe` in the current directory before searching `PATH`. Note that the many `exec git` calls are unaffected, due to an obscure quirk in Tcl's `exec` function. Typically, `git.exe` lives next to `wish.exe` (i.e. the program that is run to execute `gitk` or Git GUI) in Git for Windows, and that is the saving grace for `git.exe because `exec` searches the directory where `wish.exe` lives even before the current directory, according to https://www.tcl-lang.org/man/tcl/TclCmd/exec.htm#M24: If a directory name was not specified as part of the application name, the following directories are automatically searched in order when attempting to locate the application: The directory from which the Tcl executable was loaded. The current directory. The Windows 32-bit system directory. The Windows home directory. The directories listed in the path. The same is not true, however, for `taskkill.exe`: it lives in the Windows system directory (never mind the 32-bit, Tcl's documentation is outdated on that point, it really means `C:\Windows\system32`). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 2024-12-24gitk: Update Bulgarian translation (327t)Alexander Shopov1-345/+385 Signed-off-by: Alexander Shopov <ash@kambanaria.org> Signed-off-by: Johannes Sixt <j6t@kdbg.org> 2024-12-14gitk: offer "Copy commit ID to X11 selection" only on X11Johannes Sixt1-4/+10 This option is only useful where a selection clipboard is available, which is only the case on X11. Do not clutter the UI in other environments. Signed-off-by: Johannes Sixt <j6t@kdbg.org> 2024-12-13gitk: support auto-copy comit ID to primary clipboardAvi Halachmi (:avih)1-3/+11 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> 2024-12-13gitk: prefs dialog: refine Auto-select UIAvi Halachmi (:avih)1-4/+7 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> 2024-12-13gitk: UI text: change "SHA1 ID" to "Commit ID"Avi Halachmi (:avih)1-5/+5 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> 2024-12-09gitk: add text wrapping preferencesChristoph Sommer1-8/+27 Add a new preference "wrapdefault" which allows enabling char/word wrap. Impacts all text in the ctext widget for which no other preference exists. Also make the (existing) preference "wrapcomment" configurable graphically. Its setting impacts only the "comment" part of the ctext widget. Signed-off-by: Christoph Sommer <sommer@cms-labs.org> Signed-off-by: Johannes Sixt <j6t@kdbg.org> 2024-12-09gitk: make headings of preferences boldChristoph Sommer1-5/+5 Make preference groups like "Diff display options" stand out more. Signed-off-by: Christoph Sommer <sommer@cms-labs.org> Signed-off-by: Johannes Sixt <j6t@kdbg.org> 2024-11-24gitk: check main window visibility before waiting for it to showTobias Pietzsch1-1/+1 If the main window is already visible when gitk waits for it to become visible, gitk hangs forever. This commit adds a check whether the window is already visible. See https://wiki.tcl-lang.org/page/tkwait+visibility Signed-off-by: Tobias Pietzsch <pietzsch@mycroft.speedport.ip> Signed-off-by: Johannes Sixt <j6t@kdbg.org> 2024-11-24Makefile(s): avoid recipe prefix in conditional statementsTaylor Blau1-2/+2 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: 728b9ac0c3b93aaa4ea80280c591deb198051785 Signed-off-by: Johannes Sixt <j6t@kdbg.org> 2024-11-24doc: switch links to httpsJosh Soref1-1/+1 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: d05b08cd52cfda627f1d865bdfe6040a2c9521b5 Signed-off-by: Johannes Sixt <j6t@kdbg.org> 2024-11-24doc: update links to current pagesJosh Soref1-1/+1 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: 65175d9ea26bebeb9d69977d0e75efc0e88dbced Signed-off-by: Johannes Sixt <j6t@kdbg.org> 2023-10-26gitk: sv.po: Update Swedish translation (323t)Peter Krefting1-357/+377 Signed-off-by: Peter Krefting <peter@softwolves.pp.se> 2023-05-08gitk: escape file paths before piping to git logNico Rieck1-2/+14 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> 2023-05-08gitk: prevent overly long command linesJohannes Schindelin1-5/+19 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> 2022-05-11gitk: include y coord in recorded sash positionhalilsen1-0/+3 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> 2022-05-11gitk: trivial indentation fixhalilsen1-7/+7 No functional changes. Signed-off-by: Halil Sen <halil.sen@gmail.com> Signed-off-by: Paul Mackerras <paulus@ozlabs.org> 2020-10-03gitk: Resize panes correctly when reducing window sizePaul Mackerras1-4/+11 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> 2020-10-03gitk: replace tabs with spacesDenton Liu1-5308/+5308 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> 2020-04-13gitk: fix the context menu not appearing in the presence of submodule diffsРоман Донченко1-3/+3 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> 2020-04-13gitk: Un-hide selection in areas with non-default background colorJohannes Sixt1-0/+6 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> 2020-04-13gitk: add diff lines background colorsStefan Dotterweich1-3/+19 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> 2020-04-13gitk: be prepared to be run in a bare repositoryJunio C Hamano1-3/+2 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> 2019-12-15gitk: Preserve window dimensions on exit when not using ttk themesEric Huber1-1/+1 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> 2019-12-15gitk: don't highlight files after submodules as submodulesРоман Донченко1-2/+2 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> 2019-12-15gitk: fix branch name encoding errorKazuhiro Kato1-0/+4 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> 2019-12-15gitk: rename "commit summary" to "commit reference"Beat Bolli1-4/+4 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> 2019-09-17gitk: rename zh_CN.po to zh_cn.poDenton Liu1-0/+0 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> 2019-09-14gitk: Do not mistake unchanged lines for submodule changesGabriele Mazzotta1-2/+2 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> 2019-09-14gitk: Use right colour for remote refs in the "Tags and heads" dialogPaul Wise1-1/+8 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>