-
Notifications
You must be signed in to change notification settings - Fork 0
fast forwarding #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
hdu-hh
wants to merge
10,000
commits into
hdu-hh:master
Choose a base branch
from
git:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gitk has code and variables to use the earlier non-themed widget set, but this code is now irrelevant as gitk now always uses ttk. Clean this up. Signed-off-by: Mark Levedahl <[email protected]>
Tk through 8.6 has different approaches for handling mouse wheel / touchpad scrolling events on the different platforms, and gitk has separate code for these. But, some x11 bindings are applied on aqua as we do not have these in a clean if / then / else tree based upon platform. Let's split these bindings apart. Signed-off-by: Mark Levedahl <[email protected]>
gitk provides scrolling of several windows, uses hard-coded values for the amount of scrolling, and these values differ across platforms and widgets. The nominal value used is either 1 text line per mouse / touchpad / button event, or 5 lines. Furthermore, Tk does not scroll text widgets by 1 line when told to, this usually gets 2-3 lines of motion. The upper canvas objects holding the commit graph do scroll as defined. But, clearly no value is universally preferred, so let's give the user some control over this. Provide a single multiplier to be applied for all scroll bindings, with a value of 3 to mean the default nominal value of 3 line. This is selected both as a compromise between the various defaults across platforms, and because it is the smallest value honored by the two text widgets on the bottom of the screen. Later commits will connect this variable for actual scrolling events. Signed-off-by: Mark Levedahl <[email protected]>
gitk supports scrolling of 5 windows, but does this differently on the aqua, x11, and win32 platforms as Tk provides different events on each. TIP 171 removes some differences on win32 while altering the required bindings on x11. TIP 474, which is in Tk 8.7 and later, finally unifies all platforms on using common MouseWheel bindings. Importantly for now, TIP 171 causes delivery of MouseWheel events to the widget under the mouse cursor on win32, eliminating the need for completely different bindings on win32. Let's make some common functions to unify as much as we can in Tk 8.6. Examining the platforms shows that the default platform scrolling is overridden differently on the 3 platforms, and the nominal amount of motion achieved per mouse wheel "click" is different. win32 nominally makes everything move 5 lines per click, aqua 1 line per click, and x11 is a mixture. Part of this is due to win32 overriding all scroll events, while x11 and aqua override smaller sets. Also, note that the text widgets (the lower two panes) always scroll by 2-3 lines when given a smaller scroll amount, while the upper three canvas objects follow the requested scrolling value more accurately. First, let's have a common routine to calculate the scroll value to give to a widget in an event. This accounts for the user preference, the scale of the %D (delta) value given by the event (120 on win32, 1 on aqua, assumed 1 on x11), and must always be integer. Include negation as by convention the screen moves opposite to the MouseWheel delta. Allow setting an offset value to account for the larger minimum scrolling of text widgets. Second, let's have a common declaration of MouseWheel event bindings, as those are shared by all in Tcl9, and by aqua/win32 earlier. Bind all five display windows here. Note that the Patch/Tree widget (cflist) cannot scroll horizontally. Signed-off-by: Mark Levedahl <[email protected]>
gitk on win32 binds windows_mousewheel_redirector to all MouseWheel events in the main window. This proc determines the widget under the cursor, then determines what scroll command to give, possibly none, and issues scroll commands to the widget. The top panes get only vertical scroll events, as does the lower right Patch/Tree pane. All others get both vertical and horizontal events. These are all hard coded at +/- five lines. We now have common MouseWheel event bindings that follow user preferences for the scrolling amount, bind for only the five main display widgets, and leave the other gui elements untouched. Let's use this instead. With the scrolling preference set at 5, the users should not notice much, if any, difference. Signed-off-by: Mark Levedahl <[email protected]>
gitk has x11 mouse bindings that receive button presses, not MouseWheel events, as this is the Tk implementation through Tk 8.6. On x11, gitk translates each button event to a scrolling value of +/- 5 for the upper three panes that scroll vertically as one unit. gitk applies similar scaling for horizontal scaling of the lower-left commit details pane (ctext), but not for vertical scrolling of either of the bottom panes. Rather, the Tk default scrolling actions are used for vertical scrolling. Let's make X11 behave similarly to the just modified win32 platform. Do so by connecting vertical and horizontal scrolling events for the same items bound in 'proc bind_mousewheel' and using the same user preference values. Signed-off-by: Mark Levedahl <[email protected]>
Tk provides MouseWheel events to aqua, similar to win32. But, these events on aqua have a nominal motion value (%D) of 1, not 120 as on win32. gitk on aqua provides specific bindings only for the top 3 panes, giving a nominal scrolling amount of +/- 1 for all events. gitk includes a hidden feature providing horizontal scrolling of the commit graph, added in 5fdcbb1 ("gitk: Fixes for Mac OS X TkAqua", 2009-03-23). This horizontal scrolling is triggered by mouse events in any of the top 3 panes, and thus violates normal gui design where the object under the mouse cursor scrolls. Let's update this using the common bindings in 'proc bind_mousewheel', allowing user preferences on motion scaling to apply to all windows. The commit graph scrolling feature is removed by this, and will be added back for all platforms in a later commit. Signed-off-by: Mark Levedahl <[email protected]>
gitk's color selection dialog uses a number of "label" widgets to show the current value of each selectable color. This uses the -background color property of label widgets, and this property is overwritten when the full ui color set is refreshed. The swatch colors are set individually using code passed into the chooser dialog, so there is no common routine to set all after updating the global ui colors. Let's replace this with a single routine that does set all swatches, removing a key impediment to restoring the ui colors if the dialog is cancelled. Signed-off-by: Mark Levedahl <[email protected]>
gitk commit 5fdcbb1 ("gitk: Fixes for Mac OS X TkAqua", 2009-03-23), adds horizontal scrolling of the commit graph pane on aqua, but not on x11 or win32. Also, the horizontal scrolling is triggered by MouseWheel events attached to any of the three panes, not just the commit graph that is the only one that scrolls. It is unusual to scroll a widget that is not under the mouse, many would consider this a bug. No horizontal scrollbar is provided for this, so there is no real cue for the user that horizontal scrolling is available. We removed this aqua only feature by transitioning aqua to use the common MouseWheel bindings set. Let's add this as a feature on all platforms, and use the same approach for scaling scroll motion as we do elsewhere. For horizontal scrolling, honor only events received by the commit graph in conformance with normal GUI design. Vertical scrolling is unchanged, and events received by any of the 3 panes continue to scroll all 3 in unison. Per the ancient and long ignored CUA standards, we should add a horizontal scrollbar to the commit-graph, but gitk's interface is already very cluttered: adding a scrollbar to only one of these three panes is difficult while maintaining common pane vertical size, especially so considering the movable sash separating panes 1 & 2, and will consume yet more space. So, leave this as a hidden feature, now available on all platforms. Signed-off-by: Mark Levedahl <[email protected]>
gitk provides a dialog to configure many ui colors. Any color element changed in the dialog takes immediate effect before closing the dialog. While cancelling the dialog after changing one or more colors avoids saving the modified colors, the user must restart gitk to restore the prior color set. This unfortunate behavior results because gitk does not have a single routine to update all of the ui colors. The prior commit eliminated the key impediment to having such a routine. So, let's create a routine to update all configured colors at once, use this when modifying colors, and also invoke this after restoring the prior set if the dialog is cancelled. Signed-off-by: Mark Levedahl <[email protected]>
TclTk 8.7 (still in alpha), and 9.0 (released), implement TIP 474 that delivers uniform handling of mouse and touchpad scrolling events on all platforms, and by default bound to most widgets. TIP 474 also implements use of the Option- modifier key (Alt- key on PC, Option- key on Macs) to indicate desire for more motion per scroll wheel event, the amplification is not defined but seems to be 5x to 10x. So, for TclTk >= 8.7 we can use identical MouseWheel bindings on all platforms, and should enable use of the Option- modifier to enable larger motion. Let's do all of this, and use a 5x multiplier for the Option- modifier. This largely follows the prior win32 model, except that Tk 8.6 does not reliably use the Option- modifier because the Alt- key conflicts with builtin behavior to activate the main menubar. Presumably this conflict is addressed in the win32 Tcl9.x package. Signed-off-by: Mark Levedahl <[email protected]>
gitk uses '-encoding binary' in several places to handle non-text data. Per TIP 699, this is not recommended as there has been too much confusion and misconfiguration of binary channels, and this option is removed in Tcl 9. Tcl defines a binary channel as one that reproduces the input data exactly. As Tcl stores all data internally in unicode format, a binary channel requires 3 things: - -encoding iso8859-1 : this causes each byte of input to be translated to its unicode equivalent (may be multi-byte). - -translation lf : this avoids any translation of line endings, which by default are translated to \n on input. - -eofchar {} : this avoids any use of an end of file character, which is ctrl-z by default on Windows. The recommended '-translation binary' makes all three settings, but this is not done in gitk now. Rather, gitk uses '-encoding binary', which is an alias to '-encoding iso8859-1' removed by TIP 699, in multiple places, and -eofchar {} in one place but not all. All other files, configured in non-binary fashion, have -eofchar {}. Unix and Windows differ on line ending conventions, Tcl by default converts line endings to \n on input, and to those common on the platform on output. git emits only \n on Unix or Windows. Also, Tcl's proc gets recognizes and removes \n, \r, or \r\n as line endings, and this is used by gitk except in procs selectline and parsecommit. But, those two procs recognize any combination of \n and \r as terminating a line. So, there is no need to translate line endings on input, and using -translation binary avoids any such translation. Tcl sets eofchar to ctrl-z (ascii \0x1a) only on Windows, otherwise eofchar is {}. This provides compatibility to old DOS based codes and files originating when file systems recorded only sectors allocated, and not bytes used. git does not use ctrl-z to terminate data anywhere. Only two channels in gitk leave eofchar at the default value, both use -encoding binary now. A third one was converted in commit 681c329 ("gitk: Handle blobs containing a DOS end-of-file marker", 2009-03-16), fixing such a problem of early data termination. Using eofchar {} is correct, even if not always necessary. Tcl 9 forces change, using -translation binary per TIP 699 does what gitk needs and is backwards compatible to Tcl 8.x. Do it. Signed-off-by: Mark Levedahl <[email protected]>
gitk looks for configuration files under $(HOME)/.., and uses the typical shortcut formats to find this, e.g., ~/.config/. This relies upon Tcl expanding such constructs to replace ~ with $(HOME). But, Tcl 9 has stopped doing that for various reasons, and now supplies [file tildeexpand ...] to perform this expansion. There are a very few places that need this expansion, and all must be modified regardless of approach taken. POSIX specifies that $HOME be defined at the time of login, and both Cygwin and MSYS (underlying git for windows) set this variable. Tcl8 uses the POSIX defined pwnam to look up the underlying database record on Unix, but will get the same result as using $HOME on any POSIX compliant system. On Windows, Tcl just accesses $HOME, falling back to other environment variables if $HOME is not set. Git for Windows has $HOME defined by MSYS, so this works just as on the others. As $env(HOME) works in Tcl 8 and 9, while anything using [file tildeexpand ... ] will not, let's use the simpler approach as doing so adds no lines of code. Signed-off-by: Mark Levedahl <[email protected]>
gitk invokes many git commands expecting output in utf-8 encoding, but git accepts extended ascii (code page unknown) as utf-8 without validating, so cannot guarantee valid utf-8 on output. In particular, using any extended ascii code page, of which there are many, has long been acceptable given that everyone on a project is aware of and uses that same code page to view all data. utf-8 accepts only 7-bit ascii characters in single bytes, and any characters outside of that base set require at least two bytes. Tcl is a string based language, and transcodes all input data to an internal unicode format, and to whatever format is requested on output: "pure" binary is recoded using iso8859-1. Tcl8.x silently recodes invalid utf-8 as binary data, so extended ascii characters maintain their binary value on output but may not display correctly. Tcl 8.7 added three profiles to control this behaviour: strict (raises exceptions), replace (replaces each invalid byte with ?), and the default tcl8 maintaining the old behavior. Tcl 9 changes the default profile to strict, meaning any invalid utf-8 raises an exception that gitk does not handle. An example of this in the git repository is commit 7eb93c8 ("[PATCH] Simplify git script", 2005-09-07). This includes extended ascii characters in the author name and commit message. As a result, gitk + Tcl 9 cannot view the git repository at any point beyond that commit. Note: Tcl 9.0 has a bug, to be fixed in 9.1, where this particular condition results in a memory error causing Tcl to crash [1]. The tcl8 profile used so far has acceptable behavior given gitk's acceptance: this allows gitk to accept extended ascii though it may display incorrectly. Let's continue that behavior by overriding open to use the tcl8 profile on Tcl9 and later: Tcl 8.6 does not understand fconfigure -profile, and Tcl 8.7 maintains the tcl8 profile. [1] Per https://core.tcl-lang.org/tcl/tktview/73bb42fb3f35cd613af6fcea465e35bbfd352216 Signed-off-by: Mark Levedahl <[email protected]>
gitk in the prior commit learned to apply -profile tcl8 to all input data streams, avoiding errors on non-binary data streams whose encoding is not utf-8. But, gitk also consumes binary data streams (generally blobs from commits), and internally decodes this to support various displays. With Tcl9, errors occur in this decoding for the same reasons described in the previous commit: basically, the underlying data was not validated to conform to the given encoding, and this source encoding may not be utf-8. gitk performs this decoding using Tcl's '[encoding convert from' operator. For example, the 7th commit in gitk's history has the extended ascii value 0xA9, so gitk 9a40c50 in gitk's repository raises an exception. The error log has: unexpected byte sequence starting at index 11: '\xA9' while executing "encoding convertfrom $diffencoding $line" (procedure "parseblobdiffline" line 135) invoked from within "parseblobdiffline $ids $line" (procedure "getblobdiffline" line 16) invoked from within "getblobdiffline file6 9a40c50" ("eval" body line 1) invoked from within "eval $script" (procedure "dorunq" line 11) invoked from within "dorunq" ("after" script) This problem has a similar fix to the prior issue: we must use the tlc8 profile when converting this data. Do so, again only on Tcl9 as Tcl8.6 does not recognize -profile, and only Tcl 9.0 makes strict the default. Signed-off-by: Mark Levedahl <[email protected]>
Tcl/Tk 9.0 has been released, and has shipped in Fedora 42. Prior patches in this sequence have addressed known incompatibilities, so gitk is now operating with Tcl9. So, let's allow Tcl9. Signed-off-by: Mark Levedahl <[email protected]>
There are some trivial -Wsign-compare warnings in "object-file.c". Fix them and drop the preprocessor define that disables those warnings. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
There are a couple of users of the `the_hash_algo` macro, which implicitly depends on `the_repository`. Adapt these callers to not do so anymore, either by deriving it from already-available context or by using `the_repository->hash_algo`. The latter variant doesn't yet help to remove the global dependency, but such users will be adapted in the following commits to not use `the_repository` anymore. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
We implicitly depend on `the_repository` in `has_loose_object()`. Refactor the function to accept an `odb_source` as input that should be checked for such a loose object. This refactoring changes semantics of the function to not check the whole object database for such a loose object anymore, but instead we now only check that single source. Existing callers thus need to loop through all sources manually now. While this change may seem illogical at first, whether or not an object exists in a specific format should be answered by the source using that format. As such, we can eventually convert this into a generic function `odb_source_has_object()` that simply checks whether a given object exists in an object source. And as we will know about the format that any given source uses it allows us to derive whether the object exists in a given format. This change also makes `has_loose_object_nonlocal()` obsolete. The only caller of this function is adapted so that it skips the primary object source. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The `check_and_freshen()` functions are only used by a single caller now. Inline them into `freshen_loose_object()`. While at it, rename `check_and_freshen_odb()` to `_source()` to reflect that it works on a single object source instead of on the whole database. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
We implicitly depend on `the_repository` when freshening either loose or packed objects. Refactor these functions to instead accept an object database as input so that we can get rid of the global dependency. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
While `loose_object_info()` already accepts a repository as parameter we still have one callsite in there where we use `the_repository` to figure out the hash algorithm. Use the passed-in repository instead. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
We implicitly depend on `the_repository` when moving an object file into place in `finalize_object_file()`. Get rid of this global dependency by passing in a repository. Note that one might be pressed to inject an object database instead of a repository. But the function doesn't really care about the ODB at all. All it does is to move a file into place while checking whether there is any collision. As such, the functionality it provides is independent of the object database and only needs the repository as parameter so that it can adjust permissions of the file we are about to finalize. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When a repository is configured to have a compatibility hash algorithm we keep track of object ID mappings for loose objects via the loose object map. This map simply maps an object ID of the actual hash to the object ID of the compatibility hash. This loose object map is an inherent property of the loose files backend and thus of one specific object source. Refactor the interfaces to reflect this by requiring a `struct odb_source` as input instead of a repository. This prepares for subsequent commits where we will refactor writing of loose objects to work on a `struct odb_source`, as well. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
We do not have a backend-agnostic way to write objects into an object database. While there is `write_object_file()`, this function is rather specific to the loose object format. Introduce `odb_write_object()` to plug this gap. For now, this function is a simple wrapper around `write_object_file()` and doesn't even use the passed-in object database yet. This will change in subsequent commits, where `write_object_file()` is converted so that it works on top of an `odb_source`. `odb_write_object()` will then become responsible for deciding which source an object shall be written to. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The logic that writes loose objects still relies on `the_repository` to decide where exactly the object shall be written to. Refactor it so that the logic instead operates on a `struct odb_source` so that we can get rid of this global dependency. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The function `for_each_loose_file_in_objdir_buf()` is declared in our headers, but it is not used anywhere else than in the corresponding code file itself. Drop the declaration and inline the function into its only caller. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The function `for_each_file_in_obj_subdir()` is declared in our headers, but it is not used anywhere else than in the corresponding code file itself. Drop the declaration and mark the function as file-local. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The iterators for loose objects still rely on `the_repository`. Refactor them: - `for_each_loose_file_in_objdir()` is refactored so that the caller is now expected to pass an `odb_source` as parameter instead of the path to that source. Furthermore, it is renamed accordingly to `for_each_loose_file_in_source()`. - `for_each_loose_object()` is refactored to take in an object database now and calls the above function in a loop. This allows us to get rid of the global dependency. Adjust callers accordingly. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The function `read_loose_object()` takes a path to an object file and tries to parse it. As such, the function does not depend on any specific object database but instead acts as an ODB-independent way to read a specific file. As such, all it needs as input is a repository so that we can derive repo settings and the hash algorithm. That repository isn't passed in as a parameter though, as we implicitly depend on the global `the_repository`. Refactor the function so that we pass in the repository as a parameter. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
"git switch" and "git restore" are declared to be no longer experimental. * jt/switch-restore-no-longer-experimental: builtin: unmark git-switch and git-restore as experimental
Code clean-up. * kn/for-each-ref-skip-updates: ref-filter: use REF_ITERATOR_SEEK_SET_PREFIX instead of '1' t6302: add test combining '--start-after' with '--exclude' for-each-ref: reword the documentation for '--start-after' for-each-ref: fix documentation argument ordering ref-cache: use 'size_t' instead of int for length
The config API had a set of convenience wrapper functions that implicitly use the_repository instance; they have been removed and inlined at the calling sites. * ps/config-wo-the-repository: (21 commits) config: fix sign comparison warnings config: move Git config parsing into "environment.c" config: remove unused `the_repository` wrappers config: drop `git_config_set_multivar()` wrapper config: drop `git_config_get_multivar_gently()` wrapper config: drop `git_config_set_multivar_in_file_gently()` wrapper config: drop `git_config_set_in_file_gently()` wrapper config: drop `git_config_set()` wrapper config: drop `git_config_set_gently()` wrapper config: drop `git_config_set_in_file()` wrapper config: drop `git_config_get_bool()` wrapper config: drop `git_config_get_ulong()` wrapper config: drop `git_config_get_int()` wrapper config: drop `git_config_get_string()` wrapper config: drop `git_config_get_string()` wrapper config: drop `git_config_get_string_multi()` wrapper config: drop `git_config_get_value()` wrapper config: drop `git_config_get_value()` wrapper config: drop `git_config_get()` wrapper config: drop `git_config_clear()` wrapper ...
"git add/etc -p" now honor the diff.context configuration variable, and also they learn to honor the -U<n> command-line option. * lm/add-p-context: add-patch: add diff.context command line overrides add-patch: respect diff.context configuration t: use test_config in t4055 t: use test_grep in t3701 and t4055
Windows fixes. * js/mingw-fixes: mingw: support Windows Server 2016 again mingw_rename: support ReFS on Windows 2022 mingw: drop Windows 7-specific work-around mingw_open_existing: handle directories better
Build fix. * ps/meson-clar-decls-fix: meson: ensure correct "clar-decls.h" header is used
Interactive prompt code did not correctly strip CRLF from the end of line on Windows. * js/prompt-crlf-fix: interactive: do strip trailing CRLF from input
Test fix. * ch/t7450-recursive-clone-test-fix: t7450: inspect the correct path a broken code would write to
Doc update. * jc/doc-release-vs-clear: CodingGuidelines: clarify that S_release() does not reinitialize
Build fix. * ms/meson-with-ancient-git-wo-ls-files-dedup: meson: tolerate errors from git ls-files --deduplicate
Doc update. * kh/doc-fast-import-historical: doc: fast-import: contextualize the hardware cost
Comment fix. * jc/test-hashmap-is-still-here: test-hashmap: document why it is no longer used but still there
Signed-off-by: Junio C Hamano <[email protected]>
* 'docglobs' of github.com:ilyagr/gitk: gitk: Mention globs in description of preference to hide custom refs Signed-off-by: Johannes Sixt <[email protected]>
When finding a location for the askpass helper, git will be asked for its exec path, but if that git is not the same that called git-gui then we might mistakenly point to its helper instead. Assume that git-gui and the helper are colocated to derive its path instead. This is specially useful in macOS where a broken version of that helper is provided by the system git. [j6t: move directory to variable to help in-flight topics] Suggested-by: Mark Levedahl <[email protected]> Signed-off-by: Carlo Marcelo Arenas Belón <[email protected]> Signed-off-by: Johannes Sixt <[email protected]>
* cb/no-tcl86-on-macos: git-gui: ensure own version of git-gui--askpass is used git-gui: honor TCLTK_PATH in git-gui--askpass git-gui: retire Git Gui.app git-gui: fix dependency of GITGUI_MAIN on generator git-gui: remove uname_O in Makefile
* 'master' of https://github.com/j6t/gitk: gitk: Mention globs in description of preference to hide custom refs gitk: filter invisible upstream refs from reference list gitk: avoid duplicated upstream refs gitk i18n: Remove the locations within the Bulgarian translation gitk i18n: Update Bulgarian translation (322t) gitk: allow Tcl/Tk 9.0+ gitk: use -profile tcl8 on encoding conversions gitk: use -profile tcl8 for file input with Tcl 9 gitk: Tcl9 doesn't expand ~, use $env(HOME) gitk: switch to -translation binary gitk: update scrolling for TclTk 8.7+ / TIP 474 gitk: restore ui colors after cancelling config dialog gitk: set config dialog color swatches in one place gitk: Add user preference to hide specific references
* 'master' of https://github.com/j6t/git-gui: (21 commits) git-gui: ensure own version of git-gui--askpass is used git-gui: Allow Tcl 9.0 git-gui: use -profile tcl8 on encoding conversions git-gui: use -profile tcl8 for file input with Tcl 9 git-gui: themed.tcl: use full namespace for color git-gui: remove EOL translation for gets git-gui: honor TCLTK_PATH in git-gui--askpass git-gui: retire Git Gui.app git-gui: fix dependency of GITGUI_MAIN on generator git-gui: remove uname_O in Makefile git-gui i18n: Remove the locations within the Bulgarian translation git-gui i18n: Update Bulgarian translation (557t) git-gui: do not mix -translation binary and -encoding git-gui: replace encoding binary with iso8859-1 git-gui: translation binary defines iso8859-1 git-gui: assure -eofchar {} on all channels git-gui: use /cmd/git-gui.exe for shortcut git-gui: Windows tk_getSaveFile is not useful for shortcuts git-gui: let nice work on Windows git-gui: do not add directories to PATH on Windows ...
In `archive-zip.c:write_zip_entry()` when using a stream as input for deflating a file, the call to `git_deflate()` with Z_FINISH always expects Z_STREAM_END to be returned. Per zlib documentation[1]: If the parameter flush is set to Z_FINISH, pending input is processed, pending output is flushed and deflate returns with Z_STREAM_END if there was enough output space. If deflate returns with Z_OK or Z_BUF_ERROR, this function must be called again with Z_FINISH and more output space (updated avail_out) but no more input data, until it returns with Z_STREAM_END or an error. After deflate has returned Z_STREAM_END, the only possible operations on the stream are deflateReset or deflateEnd. In scenarios where the output buffer is not large enough to write all the compressed data, it is perfectly valid for the underlying `deflate()` to return Z_OK. Thus, expecting a single pass of `deflate()` here to always return Z_STREAM_END is a bug. Update the code to flush the deflate stream until Z_STREAM_END is returned. [1]: https://zlib.net/manual.html Helped-by: Toon Claes <[email protected]> Signed-off-by: Justin Tobler <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
In "git remote set-head", we can take varying numbers of arguments depending on whether we saw the "-d" or "-a" options. But the first argument is always the remote name. The current code is somewhat awkward in that it conditionally handles the remote name up-front like this: if (argc) remote = ...from argv[0]... and then only later decides to bail if we do not have the right number of arguments for the options we saw. This makes it hard to figure out if "remote" is always set when it needs to be. Both for humans, but also for compilers; with -Og, gcc complains that "remote" can be accessed without being initialized (although this is not true, as we'd always die with a usage message in that case). Let's instead enforce the presence of the remote argument up front, which fixes the compiler warning and is easier to understand. It does mean duplicating the code to print a usage message, but it's a single line. Noticed-by: Denton Liu <[email protected]> Signed-off-by: Jeff King <[email protected]> Tested-by: Denton Liu <[email protected]> Signed-off-by: Denton Liu <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When building with -Og on gcc 15.1.1, the build produces a warning. In practice, though, this cannot be hit because `exact` acts as a guard and that variable can only be set after `matchlen` is already initialized Assign a default value to `matchlen` so that the warning is silenced. Signed-off-by: Denton Liu <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Reduce implicit assumption and dependence on the_repository in the object-file subsystem. * ps/object-file-wo-the-repository: object-file: get rid of `the_repository` in index-related functions object-file: get rid of `the_repository` in `force_object_loose()` object-file: get rid of `the_repository` in `read_loose_object()` object-file: get rid of `the_repository` in loose object iterators object-file: remove declaration for `for_each_file_in_obj_subdir()` object-file: inline `for_each_loose_file_in_objdir_buf()` object-file: get rid of `the_repository` when writing objects odb: introduce `odb_write_object()` loose: write loose objects map via their source object-file: get rid of `the_repository` in `finalize_object_file()` object-file: get rid of `the_repository` in `loose_object_info()` object-file: get rid of `the_repository` when freshening objects object-file: inline `check_and_freshen()` functions object-file: get rid of `the_repository` in `has_loose_object()` object-file: stop using `the_hash_algo` object-file: fix -Wsign-compare warnings
"git -c alias.foo=bar foo -h baz" reported "'foo' is aliased to 'bar'" and then went on to run "git foo -h baz", which was unexpected. Tighten the rule so that alias expansion is reported only when "-h" is the sole option. * rs/tighten-alias-help: git: show alias info only with lone -h
The case where a new submodule takes a path where used to be a completely different subproject is now dealt a bit better than before. * kj/renamed-submodule: fixup! submodule: skip redundant active entries when pattern covers path fixup! submodule: prevent overwriting .gitmodules on path reuse submodule: skip redundant active entries when pattern covers path submodule: prevent overwriting .gitmodules on path reuse
Signed-off-by: Junio C Hamano <[email protected]>
Squelch false-positive compiler warning. * jk/revert-squelch-compiler-warning: revert: initialize const value
Squelch false-positive compiler warning. * dl/squelch-maybe-uninitialized: t/unit-tests/clar: fix -Wmaybe-uninitialized with -Og remote: bail early from set_head() if missing remote name
The deflate codepath in "git archive --format=zip" had a longstanding bug coming from misuse of zlib API, which has been corrected. * jt/archive-zip-deflate-fix: archive: flush deflate stream until Z_STREAM_END
Improve wording and fix typos for a couple entries part of the Git 2.51 release notes. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.