fast forwarding #1
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
These options were introduced in a series of commits from fe3ccc7 (Merge branch 'ps/config-subcommands', 2024-05-15).[1] But they were not documented here. Document this option and the negated form according to the current convention.[2] [1]: `--value` is a replacement for the `value-pattern` positional argument [2]: https://lore.kernel.org/git/[email protected]/ Acked-by: Patrick Steinhardt <[email protected]> Signed-off-by: Kristoffer Haugsbakk <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
This option was introduced in a series of commits from fe3ccc7 (Merge branch 'ps/config-subcommands', 2024-05-15) and deprecated `value-pattern`. But `value-pattern` is still used throughout the doc. The deprecated modes have been quarantined in the “Deprecated Modes” section. So let’s only use `--value=<pattern>` in the rest of the doc. Acked-by: Patrick Steinhardt <[email protected]> Signed-off-by: Kristoffer Haugsbakk <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
4e51389 (builtin/config: introduce "get" subcommand, 2024-05-06) introduced `get` and `--url` but didn’t add `--url` to the synopsis. Acked-by: Patrick Steinhardt <[email protected]> Signed-off-by: Kristoffer Haugsbakk <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Previous commit has plugged one leak in the normal code path, but there is an early exit that leaves without releasing any resources acquired in the function. Signed-off-by: Junio C Hamano <[email protected]>
After going through the "failed" label, load_bitmap() will return -1,
and its caller (either prepare_bitmap_walk() or prepare_bitmap_git())
will then call free_bitmap_index().
That function would have done:
struct stored_bitmap *sb;
kh_foreach_value(b->bitmaps, sb {
ewah_pool_free(sb->root);
free(sb);
});
, but won't since load_bitmap() already called kh_destroy_oid_map() and
NULL'd the "bitmaps" pointer from within its "failed" label. Thus if you
got part of the way through loading bitmap entries and then failed, you
would leak all of the previous entries that you were able to load
successfully.
The solution is to remove the error handling code in load_bitmap(), because
its caller will always call free_bitmap_index() in case of an error.
Signed-off-by: Taylor Blau <[email protected]>
Signed-off-by: Lidong Yan <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
The comment in pack-bitmap.c:test_bitmap_commits(), suggests that we can avoid reading the commit table altogether. However, this comment is misleading. The reason we load bitmap entries here is because test_bitmap_commits() needs to print the commit IDs from the bitmap, and we must read the bitmap entries to obtain those commit IDs. So reword this comment. Signed-off-by: Lidong Yan <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
t5310 lacks a test to ensure git works correctly when commit bitmap data is corrupted. So this patch add test helper in pack-bitmap.c to list each commit bitmap position in bitmap file and `load corrupt bitmap` test case in t/t5310 to corrupt a commit bitmap before loading it. Signed-off-by: Lidong Yan <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The `raw_object_store` structure is the central entry point for reading and writing objects in a repository. The main purpose of this structure is to manage object directories and provide an interface to access and write objects in those object directories. Right now, many of the functions associated with the raw object store implicitly rely on `the_repository` to get access to its `objects` pointer, which is the `raw_object_store`. As we want to generally get rid of using `the_repository` across our codebase we will have to convert this implicit dependency on this global variable into an explicit parameter. This conversion can be done by simply passing in an explicit pointer to a repository and then using its `->objects` pointer. But there is a second effort underway, which is to make the object subsystem more selfcontained so that we can eventually have pluggable object backends. As such, passing in a repository wouldn't make a ton of sense, and the goal is to convert the object store interfaces such that we always pass in a reference to the `raw_object_store` instead. This will expose the `raw_object_store` type to a lot more callers though, which surfaces that this type is named somewhat awkwardly. The "raw_" prefix makes readers wonder whether there is a non-raw variant of the object store, but there isn't. Furthermore, we nowadays want to name functions in a way that they can be clearly attributed to a specific subsystem, but calling them e.g. `raw_object_store_has_object()` is just too unwieldy, even when dropping the "raw_" prefix. Instead, rename the structure to `object_database`. This term is already used a lot throughout our codebase, and it cannot easily be mistaken for "object directories", either. Furthermore, its acronym ODB is already well-known and works well as part of a function's name, like for example `odb_has_object()`. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The `object_directory` structure is used as an access point for a single
object directory like ".git/objects". While the structure isn't yet
fully self-contained, the intent is for it to eventually contain all
information required to access objects in one specific location.
While the name "object directory" is a good fit for now, this will
change over time as we continue with the agenda to make pluggable object
databases a thing. Eventually, objects may not be accessed via any kind
of directory at all anymore, but they could instead be backed by any
kind of durable storage mechanism. While it seems quite far-fetched for
now, it is thinkable that eventually this might even be some form of a
database, for example.
As such, the current name of this structure will become worse over time
as we evolve into the direction of pluggable ODBs. Immediate next steps
will start to carve out proper self-contained object directories, which
requires us to pass in these object directories as parameters. Based on
our modern naming schema this means that those functions should then be
named after their subsystem, which means that we would start to bake the
current name into the codebase more and more.
Let's preempt this by renaming the structure. There have been a couple
alternatives that were discussed:
- `odb_backend` was discarded because it led to the association that
one object database has a single backend, but the model is that one
alternate has one backend. Furthermore, "backend" is more about the
actual backing implementation and less about the high-level concept.
- `odb_alternate` was discarded because it is a bit of a stretch to
also call the main object directory an "alternate".
Instead, pick `odb_source` as the new name. It makes it sufficiently
clear that there can be multiple sources and does not cause confusion
when mixed with the already-existing "alternate" terminology.
In the future, this change allows us to easily introduce for example a
`odb_files_source` and other format-specific implementations.
Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
In the preceding commits we have renamed the structures contained in
"object-store.h" to `struct object_database` and `struct odb_backend`.
As such, the code files "object-store.{c,h}" are confusingly named now.
Rename them to "odb.{c,h}" accordingly.
Signed-off-by: Patrick Steinhardt <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
In subsequent commits we'll get rid of our use of `the_repository` in "odb.c" in favor of explicitly passing in a `struct object_database` or a `struct odb_source`. In some cases though we'll need access to the repository, for example to read a config value from it, but we don't have a way to access the repository owning a specific object database. Introduce parent pointers for `struct object_database` to its owning repository as well as for `struct odb_source` to its owning object database, which will allow us to adapt those use cases. Note that this change requires us to pass through the object database to `link_alt_odb_entry()` so that we can set up the parent pointers for any source there. The callchain is adapted to pass through the object database accordingly. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Get rid of our dependency on `the_repository` in `find_odb()` by passing in the object database in which we want to search for the source and adjusting all callers. Rename the function to `odb_find_source()`. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Get rid of our dependency on `the_repository` in `assert_oid_type()` by passing in the object database as a parameter and adjusting all callers. Rename the function to `odb_assert_oid_type()`. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Get rid of our dependency on `the_repository` in `odb_mkstemp()` by passing in the object database as a parameter and adjusting all callers. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The functions to manage alternates all depend on `the_repository`. Refactor them to accept an object database as a parameter and adjust all callers. The functions are renamed accordingly. Note that right now the situation is still somewhat weird because we end up using the object store path provided by the object store's repository anyway. Consequently, we could have instead passed in a pointer to the repository instead of passing in the pointer to the object store. This will be addressed in subsequent commits though, where we will start to use the path owned by the object store itself. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
There are a couple of iterator-style functions that execute a callback for each instance of a given set, all of which currently depend on `the_repository`. Refactor them to instead take an object database as parameter so that we can get rid of this dependency. Rename the functions accordingly. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The functions `set_temporary_primary_odb()` and `restore_primary_odb()` are responsible for managing a temporary primary source for the database. Both of these functions implicitly rely on `the_repository`. Refactor them to instead take an explicit object database parameter as argument and adjust callers. Rename the functions accordingly. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The "--recursive" flag for git-grep(1) allows users to grep for a string across submodule boundaries. To make this work we add each submodule's object sources to our own object database so that the objects can be accessed directly. The infrastructure for this depends on a global string list of submodule paths. The caller is expected to call `add_submodule_odb_by_path()` for each source and the object database will then eventually register all submodule sources via `do_oid_object_info_extended()` in case it isn't able to look up a specific object. This reliance on global state is of course suboptimal with regards to our libification efforts. Refactor the logic so that the list of submodule sources is instead tracked in the object database itself. This allows us to lose the condition of `r == the_repository` before registering submodule sources as we only ever add submodule sources to `the_repository` anyway. As such, behaviour before and after this refactoring should always be the same. Rename the functions accordingly. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
All of the external functions provided by the object database subsystem don't depend on `the_repository` anymore, but some internal functions still do. Refactor those cases by plumbing through the repository that owns the object database. This change allows us to get rid of the `USE_THE_REPOSITORY_VARIABLE` preprocessor define. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Rename `oid_object_info()` to `odb_read_object_info()` as well as their `_extended()` variant to match other functions related to the object database and our modern coding guidelines. Introduce compatibility wrappers so that any in-flight topics will continue to compile. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Rename `repo_read_object_file()` to `odb_read_object()` to match other functions related to the object database and our modern coding guidelines. Introduce a compatibility wrapper so that any in-flight topics will continue to compile. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Rename `has_object()` to `odb_has_object()` to match other functions related to the object database and our modern coding guidelines. Introduce a compatibility wrapper so that any in-flight topics will continue to compile. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Rename `pretend_object_file()` to `odb_pretend_object()` to match other functions related to the object database and our modern coding guidelines. No compatibility wrapper is introduced as the function is not used a lot throughout our codebase. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Rename `read_object_with_reference()` to `odb_read_object_peeled()` to match other functions related to the object database and our modern coding guidelines. Furthermore though, the old name didn't really describe very well what this function actually does, which is to walk down any commit and tag objects until an object of the required type has been found. This is generally referred to as "peeling", so the new name should be way more descriptive. No compatibility wrapper is introduced as the function is not used a lot throughout our codebase. Signed-off-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Right now, SHA-1 is the default hash algorithm in Git. However, this may change in the future. We have many places in our code that use the SHA-1 constant to indicate the default hash if none is specified, but it will end up being more practical to specify this explicitly and clearly using a constant for whatever the default hash algorithm is. Then, if we decide to change it in the future, we can simply replace the constant representing the default with a new value. For these reasons, introduce GIT_HASH_DEFAULT to represent the default hash algorithm. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
We have a a variety of uses of GIT_HASH_SHA1 littered throughout our code. Some of these really mean to represent specifically SHA-1, but some actually represent the original hash algorithm used in Git which is implied by older, legacy formats and protocols which do not contain hash information. For instance, the bundle v1 and v2 formats do not contain hash algorithm information, and thus SHA-1 is implied by the use of these formats. Add a constant for documentary purposes which indicates this value. It will always be the same as SHA-1, since this is an essential part of these formats, but its use indicates this particular reason and not any other reason why SHA-1 might be used. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
We have some commands that can operate inside or outside a repository. If we're operating outside a repository, we clearly cannot use the repository's hash algorithm as a default since it doesn't exist, so instead, let's pick the default instead of specifically SHA-1. Right now this results in no functional change since the default is SHA-1, but that may change in the future. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
We have a large variety of data formats and protocols where no hash algorithm was defined and the default was assumed to always be SHA-1. Instead of explicitly stating SHA-1, let's use the constant to represent the legacy hash algorithm (which is still SHA-1) so that it's clear for documentary purposes that it's a legacy fallback option and not an intentional choice to use SHA-1. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
When we define a new repository format with REPOSITORY_FORMAT_INIT, we always use GIT_HASH_SHA1, and this value ends up getting used as the default value to initialize a repository if none of the command line, environment, or config tell us to do otherwise. Because we might not always want to use SHA-1 as the default, let's instead specify the default hash algorithm constant so that we will use whatever the specified default is. However, we also need to continue to read older repositories. If we're in a v0 repository or extensions.objectformat is not set, then we must continue to default to the original hash algorithm: SHA-1. If an algorithm is set explicitly, however, it will override the hash_algo member of the repository_format struct and we'll get the right value. Similarly, if the repository was initialized before Git 0.99.3, then it may lack a core.repositoryformatversion key, and some repositories lack a config file altogether. In both cases, format->version is -1 and we need to assume that SHA-1 is in use. Because clear_repository_format reinitializes the struct repository_format and therefore sets the hash_algo member to the default (which could in the future not be SHA-1), we need to reset this member explicitly. We know, however, that at the point we call read_repository_format, we are actually reading an existing repository and not initializing a new one or operating outside of a repository, so we are not changing the default behavior back to SHA-1 if the default algorithm is different. It is potentially questionable that we ignore all repository configuration if there is a config file but it doesn't have core.repositoryformatversion set, in which case we reset all of the configuration to the default. However, it is unclear what the right thing to do instead with such an old repository is and a simple git init will add the missing entry, so for now, we simply honor what the existing code does and reset the value to the default, simply adding our initialization to SHA-1. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Right now, the default compile-time hash is SHA-1. However, in the future, this might change and it would be helpful to gracefully handle this case in our testsuite. To avoid making these assumptions, let's introduce a variable that contains the built-in default hash and use it in our setup code as the fallback value if no hash was explicitly set. For now, this is always SHA-1, but in a future commit, we'll allow adjusting this and the variable will be more useful. To allow us to make our tests more robust, allow test_oid to take the --hash=builtin option to specify this hash, whatever it is. Additionally, add a DEFAULT_HASH_ALGORITHM prerequisite to check for the compile-time hash. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Meson-based build update. * ps/meson-cleanups: ci: use Meson's new `--slice` option meson: update subproject wrappers meson: fix lookup of shell on MINGW64 meson: clean up unnecessary variables meson: improve summary of auto-detected features meson: stop printing 'https' option twice in our summaries meson: stop discovering native version of Python
Docfix. * rh/doc-glob-pathspec-fix: doc: correct doc for glob pathspec
Doc mark-up updates. * ja/doc-git-log-markup: doc: git-log: convert log config to new doc format doc: git-log: convert diff options to new doc format doc: git-log: convert pretty formats to new doc format doc: git-log: convert pretty options to new doc format doc: git-log: convert rev list options to new doc format doc: git-log: convert line range format to new doc format doc: git-log: convert line range options to new doc format doc: git-log convert rev-list-description to new doc format doc: convert git-log to new documentation format
Futz with SIGCHLD handling in "git daemon". * cb/daemon-reap-children: daemon: use sigaction() to install child_handler() compat/mingw: allow sigaction(SIGCHLD)
The gpg.program configuration variable, which names a pathname to the (custom) GPG compatible program, can now be spelled with ~tilde expansion. * jb/gpg-program-variable-is-a-pathname: gpg-interface: expand gpg.program as a path
git-gui clones a repository by invoking git-plumbing commands, in proc do_clone, rather than using git-clone. The justification was that the low-level commands are guaranteed to provide a stable interface, while the higher level commands such as git-clone may not be stable. This approach requires git-gui to continually evolve by mirroring new features in git itself, which has not happened, while the user interface in git-clone has proven very stable. Also, git-gui does directly call many other non-plumbing commands in git's repertoire. do_clone's last significant functionality change was in 2015, and updates are required for shallow clones, the reftable backend, cloning from linked worktrees, and perhaps other features and bugs. For instance, I had reports of git-gui failing to correctly clone repositories prior to 2015, resulting in essentially the patch given here. The only significant work was supporting .gitfile linked worktrees unknown to do_clone, but supported by git-clone, and none regarding the interface to git-clone itself. That interface is clearly stable enough to not be a problem. Supporting new use-cases with this requires exposing new options in the clone dialog, then passing flags to git-clone. This avoids updating do_clone to understand those options, reducing the maintenance burdens. So, teach git-gui to use git-clone. This change is in one patch as there is no obvious incremental path to migration. The existing dialog / options / status screen are unchanged, the known user-visible changes are that cloning from a working directory linked by a gitfile now works, there is no auto-fallback to a full copy when cloning linked workdirs and worktrees (meaning git-clone fails unless a full or shared copy is selected), and messages displayed are from git-clone. Signed-off-by: Mark Levedahl <[email protected]>
git-gui's default clone method is git-clone's default, and this uses hardlinks rather than copying the objects directory for local repositories. However, this method explicitly fails if a symlink (or .gitfile) exists in the path to the objects directory. Thus, the default clone option fails for worktrees created by git-new-workdir or git-worktree. git-gui's original do_clone trapped this error for a symlinked git-new-workdir tree, directly falling back to a full clone, while the updated git-gui using git-clone does not. (The old do_clone could not handle gitfile linked worktrees, however). Let's apply the more friendly fallback to a full clone in both these cases where git-clone behavior throws an error on the default method. Signed-off-by: Mark Levedahl <[email protected]>
git-gui implements its own approach to locating and running various git subcommands, bypassing git's capabilities for running git-*. This was written in 2007: at that time, many git commands were shell-scripts stored in $(git --exec-path), git's run-command api was not well adapted to Windows and had serious performance issues when it worked at all, and running subcommand 'git foo' as 'git-foo' was common and fully supported. On Windows, git-gui searches $(git --exec-path) for builtin commands, then attempts to find an interpreter on PATH to run those, invoking these differently than on other platforms. For instance, the explicit shebang #!/usr/bin/perl found in a script will be run by the first Perl interpreter found on $PATH, which might not be at that specific location so could be different than what git would run. The various issues leading to the current implemention no longer exist. Most git commands are now builtins, links to run those are not installed in $(git --exec-path) by default (the "dashless" form is recommended instead), and git's run-command api works well everywhere. So, let's use git to launch its subcommands on all platforms. Do so by modifying procs git_read and git_write to use the "dashless" form for invoking git commands, avoiding the search for git-<foo>. This leaves _git_cmd unused with cleanup in a later patch. Signed-off-by: Mark Levedahl <[email protected]>
gitexec looks up and caches the method to execute git subcommands using the long deprecated dashed form if found in $(git--exec-path). But, git_read and git_write now use the dashless form, by-passing gitexec. This leaves two remaining uses of gitexec: one during startup to define use of an ssh_key helper, and one in the about dialog box. These are neither performance critical nor likely to be called more than once, so do not justify an otherwise unused cacheing system. Let's change those two uses, making gitexec unused. This allows removing gitexec and _git_cmd. Signed-off-by: Mark Levedahl <[email protected]>
git-gui has _search_exe as needed to give the executable suffix (.exe) on Windows. But, the prior commit eliminated the only user of this variable. Delete it. Signed-off-by: Mark Levedahl <[email protected]>
* ml/tcl86:
git-gui: remove non-ttk code
git-gui: remove ${NS} indirection for ttk
git-gui: always use themed widgets from ttk
git-gui: remove redundant check for Tk >= 8.5
git-gui: remove unreachable Tk 8.4 code
git-gui: Make TclTk 8.6 the minimum, allow 8.7
Signed-off-by: Johannes Sixt <[email protected]>
* ml/abandon-old-versions: git-gui: eliminate _search_exe git-gui: remove procs gitexec and _git_cmd git-gui: use dashless 'git cmd' form for read/write git-gui: default to full copy for linked worktrees git-gui: use git-clone git-gui: remove unused git-version git-gui: use git_init to create new repository dir git-gui: git-remote is always available git-gui: git merge understands --strategy=recursive git-gui: git-diff knows submodules and textconv git-gui: git-blame understands -w and textconv git-gui: git rev-parse knows show_toplevel git-gui: use git-branch --show-current git-gui: git-diff-index always knows submodules git-gui: git ls-files knows --exclude-standard git-gui: require git >= 2.36 Signed-off-by: Johannes Sixt <[email protected]>
* ti/support-sha256: gitk: Add support of SHA256 repositories
* mr/sort-refs-by-type: gitk: separate upstream refs when using the sort-by-type option gitk: make 'sort-refs-by-type' optional and persistent gitk: sort by ref type on the 'tags and heads' view
* 'ml/abandon-old-version' (early part):
gitk: allow horizontal commit-graph scrolling
gitk: update aqua scrolling for TclTk 8.6 / TIP171
gitk: update x11 scrolling for TclTk 8.6 / TIP 171
gitk: update win32 scrolling for Tk 8.6 / TIP 171
gitk: mousewheel scrolling functions for Tk 8.6
gitk: wheel scrolling multiplier preference
gitk: separate x11 / win32 / aqua Mouse bindings
gitk: remove non-ttk support code
gitk: replace ${NS} with ttk
gitk: always use themed Tk (ttk)
gitk: use $config_variables as list for save/restore
gitk: remove implementations for Tcl/Tk < 8.6
gitk: Make TclTk 8.6 the minimum, allow 8.7
gitk: remove code targeting git <= 1.7.2
gitk: require git >= 2.20
An earlier commit remove the only option that was available under "General options". We don't need the header for the empty section. Signed-off-by: Johannes Sixt <[email protected]>
* 'master' of https://github.com/j6t/gitk: (21 commits) gitk: remove header of now empty section "General options" gitk: separate upstream refs when using the sort-by-type option gitk: make 'sort-refs-by-type' optional and persistent gitk: sort by ref type on the 'tags and heads' view gitk: choosefont - remove a stray debugging line gitk: allow horizontal commit-graph scrolling gitk: update aqua scrolling for TclTk 8.6 / TIP171 gitk: update x11 scrolling for TclTk 8.6 / TIP 171 gitk: update win32 scrolling for Tk 8.6 / TIP 171 gitk: mousewheel scrolling functions for Tk 8.6 gitk: wheel scrolling multiplier preference gitk: separate x11 / win32 / aqua Mouse bindings gitk: remove non-ttk support code gitk: replace ${NS} with ttk gitk: always use themed Tk (ttk) gitk: use $config_variables as list for save/restore gitk: remove implementations for Tcl/Tk < 8.6 gitk: Make TclTk 8.6 the minimum, allow 8.7 gitk: remove code targeting git <= 1.7.2 gitk: require git >= 2.20 ...
* 'master' of https://github.com/j6t/git-gui: (26 commits) git-gui: eliminate _search_exe git-gui: remove procs gitexec and _git_cmd git-gui: use dashless 'git cmd' form for read/write git-gui: default to full copy for linked worktrees git-gui: use git-clone git-gui: remove non-ttk code git-gui: remove ${NS} indirection for ttk git-gui: always use themed widgets from ttk git-gui: remove redundant check for Tk >= 8.5 git-gui: remove unreachable Tk 8.4 code git-gui: remove unused git-version git-gui: use git_init to create new repository dir git-gui: git-remote is always available git-gui: git merge understands --strategy=recursive git-gui: git-diff knows submodules and textconv git-gui: git-blame understands -w and textconv git-gui: git rev-parse knows show_toplevel git-gui: use git-branch --show-current git-gui: git-diff-index always knows submodules git-gui: git ls-files knows --exclude-standard ...
Lift the limitation to use changed-path filter in "git log" so that it can be used for a pathspec with multiple literal paths. * ly/changed-paths-traversal: bloom: optimize multiple pathspec items in revision revision: make helper for pathspec to bloom keyvec bloom: replace struct bloom_key * with struct bloom_keyvec bloom: rename function operates on bloom_key bloom: add test helper to return murmur3 hash
Our <sane-ctype.h> header file relied on that the system-supplied <ctype.h> header is not later included, which would override our macro definitions, but "amazon linux" broke this assumption. Fix this by preemptively including <ctype.h> near the beginning of <sane-ctype.h> ourselves. * ps/sane-ctype-workaround: sane-ctype: fix compiler error on Amazon Linux 2
Clean up the way how signature on commit objects are exported to and imported from fast-import stream. * cc/fast-import-export-signature-names: fast-(import|export): improve on commit signature output format
Signed-off-by: Junio C Hamano <[email protected]>
Declare weather-balloon we raised for "bool" type 18 months ago a success and officially allow using the type in our codebase. * pw/adopt-c99-bool-officially: strbuf: convert predicates to return bool git-compat-util: convert string predicates to return bool CodingGuidelines: allow the use of bool
GIT_TEST_INSTALLED was not honored in the recent topic related to SHA256 hashes, which has been corrected. * kl/test-installed-fix: test-lib: respect GIT_TEST_INSTALLED when querying default hash
Remove a redundant member from kvi struct. * pw/config-kvi-remove-path: config: remove unneeded struct field
Clean-up compat/bswap.h mess. * ss/compat-bswap-revamp: bswap.h: provide a built-in based version of bswap32/64 if possible bswap.h: remove optimized x86 version of bswap32/64 bswap.h: always overwrite ntohl/ ntohll macros bswap.h: define GIT_LITTLE_ENDIAN on msvc as little endian bswap.h: add support for __BYTE_ORDER__
Meson-based build did not handle libexecdir setting correctly, which has been corrected. * rj/meson-libexecdir-fix: po/meson.build: add missing 'ga' language code meson: fix installation when -Dlibexexdir is set
Document that we do not require "real" name when signing your patches off. * bc/contribution-under-non-real-names: SubmittingPatches: allow non-real name contributions
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.