-
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
* 'strip-post-hooks' of github.com:orgads/git-gui: git-gui: strip the commit message after running commit-msg hook Signed-off-by: Johannes Sixt <[email protected]>
The string_list_split_in_place() function was updated by 52acddf (string-list: multi-delimiter `string_list_split_in_place()`, 2023-04-24) to take more than one delimiter characters, hoping that we can later use it to replace our uses of strtok(). We however did not make a matching change to the string_list_split() function, which is very similar. Before giving both functions more features in future commits, allow string_list_split() to also take more than one delimiter characters to make them closer to each other. Signed-off-by: Junio C Hamano <[email protected]>
Thanks to the previous step, the only difference between these two related functions is that string_list_split() works on a string without modifying its contents (i.e. taking "const char *") and the resulting pieces of strings are their own copies in a string list, while string_list_split_in_place() works on a mutable string and the resulting pieces of strings come from the original string. Consolidate their implementations into a single helper function, and make them a thin wrapper around it. We can later add an extra flags parameter to extend both of these functions by updating only the internal helper function. Signed-off-by: Junio C Hamano <[email protected]>
Teach the unified split_string() to take an optional "flags" word, and define the first flag STRING_LIST_SPLIT_TRIM to cause the split pieces to be trimmed before they are placed in the string list. Signed-off-by: Junio C Hamano <[email protected]>
The code to parse this configuration variable, whose value is a comma-separated list of known tokens like "ignore-space-change" and "ignore-all-space", uses string_list_split() to split the value into pieces, and then places each piece of string in a strbuf to trim, before comparing the result with the list of known tokens. Thanks to the previous steps, now string_list_split() can trim the resulting pieces before it places them in the string list. Use it to simplify the code. Signed-off-by: Junio C Hamano <[email protected]>
Teach the unified split_string() machinery a new flag bit, STRING_LIST_SPLIT_NONEMPTY, to cause empty split pieces to be omitted from the resulting string list. Signed-off-by: Junio C Hamano <[email protected]>
Thanks to the new STRING_LIST_SPLIT_NONEMPTY flag, a common pattern to split a string into a string list and then remove empty items in the resulting list is no longer needed. Instead, just tell the string_list_split*() to omit empty ones while splitting. Signed-off-by: Junio C Hamano <[email protected]>
* jc/string-list-split: string-list: split-then-remove-empty can be done while splitting string-list: optionally omit empty string pieces in string_list_split*() diff: simplify parsing of diff.colormovedws string-list: optionally trim string pieces split by string_list_split*() string-list: unify string_list_split* functions string-list: align string_list_split() with its _in_place() counterpart string-list: report programming error with BUG
strbuf is a very good data structure to work with string data without having to worry about running past the end of the string, but strbuf_split() is a wrong API and an array of strbuf that the function produces is a wrong thing to use in general. You do not edit these N strings split out of a single strbuf simultaneously. Often it is much better off to split a string into string_list and work with the resulting strings. wt-status.c:abbrev_oid_in_line() takes one line of rebase todo list (like "pick e813a02 title"), and for instructions that has an object name as the second token on the line, replace the object name with its unique abbreviation. After splitting these tokens out of a single line, no simultaneous edit on any of these pieces of string that takes advantage of strbuf API takes place. The final string is composed with strbuf API, but these split pieces are merely used as pieces of strings and there is no need for them to be stored in individual strbuf. Instead, split the line into a string_list, and compose the final string using these pieces. Signed-off-by: Junio C Hamano <[email protected]>
When you pass a structure by value, the callee can modify the contents of the structure that was passed in without having to worry about changing the structure the caller has. Passing structure by value sometimes (but not very often) can be a valid way to give callee a temporary variable it can freely modify. But not a structure with members that are pointers, like a strbuf. builtin/clean.c:list_and_choose() reads a line interactively from the user, and passes the line (in a strbuf) to parse_choice() by value, which then munges by replacing ',' with ' ' (to accept both comma and space separated list of choices). But because the strbuf passed by value still shares the underlying character array buf[], this ends up munging the caller's strbuf contents. This is a catastrophe waiting to happen. If the callee causes the strbuf to be reallocated, the buf[] the caller has will become dangling, and when the caller does strbuf_release(), it would result in double-free. Stop calling the function with misleading call-by-value with strbuf. Signed-off-by: Junio C Hamano <[email protected]>
builtin/clean.c:parse_choice() is fed a single line of input, which is space or comma separated list of tokens, and a list of menu items. It parses the tokens into number ranges (e.g. 1-3 that means the first three items) or string prefix (e.g. 's' to choose the menu item "(s)elect") that specify the elements in the menu item list, and tells the caller which ones are chosen. For parsing the input string, it uses strbuf_split() to split it into bunch of strbufs. Instead use string_list_split_in_place(), for a few reasons. * strbuf_split() is a bad API function to use, that yields an array of strbuf that is a bad data structure to use in general. * string_list_split_in_place() allows you to split with "comma or space"; the current code has to preprocess the input string to replace comma with space because strbuf_split() does not allow this. Signed-off-by: Junio C Hamano <[email protected]>
The callee parse_choice() only needs to access a NUL-terminated string; instead of insisting to take a pointer to a strbuf, just take a pointer to a character array. Signed-off-by: Junio C Hamano <[email protected]>
builtin/clean.c:filter_by_patterns_cmd() interactively reads a line that has exclude patterns from the user and splits the line into a list of patterns. It uses the strbuf_split() so that each split piece can then trimmed. There is no need to use strbuf anymore, thanks to the recent enhancement to string_list_split*() family that allows us to trim the pieces split into a string_list. Signed-off-by: Junio C Hamano <[email protected]>
When reading merge instructions from the standard input, the program reads from the standard input, splits the line into tokens at whitespace, and trims each of them before using. We no longer need to use strbuf just for trimming, as string_list_split*() family can trim while splitting a string. Signed-off-by: Junio C Hamano <[email protected]>
When reading copy instructions from the standard input, the program reads a line, splits it into tokens at whitespace, and trims each of the tokens before using. We no longer need to use strbuf just to be able to trim, as string_list_split*() family now can trim while splitting a string. Retire the use of strbuf_split() from this code path. Note that this loop is a bit sloppy in that it ensures at least there are two tokens on each line, but ignores if there are extra tokens on the line. Tightening it is outside the scope of this series. Signed-off-by: Junio C Hamano <[email protected]>
When parsing an old-style GIT_CONFIG_PARAMETERS environment variable, the code parses key=value pairs by splitting them at '=' into an array of strbuf's. As strbuf_split() leaves the delimiter at the end of the split piece, the code has to manually trim it. If we split with string_list_split(), that becomes unnecessary. Retire the use of strbuf_split() from this code path. Note that the max parameter of string_list_split() is of an ergonomically iffy design---it specifies the maximum number of times the function is allowed to split, which means that in order to split a text into up to 2 pieces, you have to pass 1, not 2. Signed-off-by: Junio C Hamano <[email protected]>
environment.c:get_git_namespace() learns the raw namespace from an environment variable, splits it at "/", and appends them after "refs/namespaces/"; the reason why it splits first is so that an empty string resulting from double slashes can be omitted. The split pieces do not need to be edited in any way, so an array of strbufs is a wrong data structure to use. Instead split into a string list and use the pieces from there. Signed-off-by: Junio C Hamano <[email protected]>
The code to read status from subprocess reads one packet line and tries to find "status=<foo>". It is way overkill to split the line into an array of two strbufs to extract <foo>. Signed-off-by: Junio C Hamano <[email protected]>
strbuf_trim_trailing_newline() removes a LF or a CRLF from the tail of a string. If the code plans to call strbuf_trim() immediately after doing so, the code is better off skipping the EOL trimming in the first place. After all, LF/CRLF at the end is a mere special case of whitespaces at the end of the string, which will be removed by strbuf_rtrim() anyway. Signed-off-by: Junio C Hamano <[email protected]>
tr2_cfg_load_patterns() and tr2_load_env_vars() functions are functions with very similar structure that each reads an environment variable, splits its value at the ',' boundaries, and trims the resulting string pieces into an array of strbufs. But the code paths that later use these strbufs take no advantage of the strbuf-ness of the result (they do not benefit from <ptr,len> representation to avoid having to run strlen(<ptr>), for example). Simplify the code by teaching these functions to split into a string list instead; even the trimming comes for free ;-). Signed-off-by: Junio C Hamano <[email protected]>
Replace the use a list-based priority queue whose order is maintained by commit_list_insert_by_date() with a prio_queue. This avoids quadratic worst-case complexity. And in the somewhat contrived example of describing the 4751 commits from v2.41.0 to v2.47.0 in one go (to get a sizable chunk of describe work with minimal ref loading overhead) it's significantly faster: Benchmark 1: ./git_2.50.1 describe $(git rev-list v2.41.0..v2.47.0) Time (mean ± σ): 1.558 s ± 0.002 s [User: 1.492 s, System: 0.051 s] Range (min … max): 1.557 s … 1.562 s 10 runs Benchmark 2: ./git describe $(git rev-list v2.41.0..v2.47.0) Time (mean ± σ): 1.209 s ± 0.006 s [User: 1.143 s, System: 0.051 s] Range (min … max): 1.201 s … 1.219 s 10 runs Summary ./git describe $(git rev-list v2.41.0..v2.47.0) ran 1.29 ± 0.01 times faster than ./git_2.50.1 describe $(git rev-list v2.41.0..v2.47.0) Signed-off-by: René Scharfe <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Optimize the sequence get+put to peek+replace to avoid one unnecessary heap rebalance. Do that by tracking partial get operations in a prio_queue wrapper, struct lazy_queue, and using wrapper functions that turn get into peek and put into replace as needed. This is simpler than tracking the state explicitly in the calling code. We get a nice speedup on top of the previous patch's conversion to prio_queue: Benchmark 1: ./git_2.50.1 describe $(git rev-list v2.41.0..v2.47.0) Time (mean ± σ): 1.559 s ± 0.002 s [User: 1.493 s, System: 0.051 s] Range (min … max): 1.556 s … 1.563 s 10 runs Benchmark 2: ./git_describe_pq describe $(git rev-list v2.41.0..v2.47.0) Time (mean ± σ): 1.204 s ± 0.001 s [User: 1.138 s, System: 0.051 s] Range (min … max): 1.202 s … 1.205 s 10 runs Benchmark 3: ./git describe $(git rev-list v2.41.0..v2.47.0) Time (mean ± σ): 850.9 ms ± 1.6 ms [User: 786.6 ms, System: 49.8 ms] Range (min … max): 849.1 ms … 854.1 ms 10 runs Summary ./git describe $(git rev-list v2.41.0..v2.47.0) ran 1.41 ± 0.00 times faster than ./git_describe_pq describe $(git rev-list v2.41.0..v2.47.0) 1.83 ± 0.00 times faster than ./git_2.50.1 describe $(git rev-list v2.41.0..v2.47.0) Signed-off-by: René Scharfe <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
CreateFileW() requires FILE_FLAG_BACKUP_SEMANTICS to create a directory handle [1] and errors out with ERROR_ACCESS_DENIED without this flag. Fall back to accessing Directory handles this way. [1] https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew#directories This fixes git-for-windows#5068 Signed-off-by: Matthias Aßhauer <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
In ac33519 (mingw: restrict file handle inheritance only on Windows 7 and later, 2019-11-22), I introduced code to safe-guard the defense-in-depth handling that restricts handles' inheritance so that it would work with Windows 7, too. Let's revert this patch: Git for Windows dropped supporting Windows 7 (and Windows 8) directly after Git for Windows v2.46.2. For full details, see https://gitforwindows.org/requirements#windows-version. Actually, on second thought: revert only the part that makes this handle inheritance restriction logic optional and that suggests to open a bug report if it fails, but keep the fall-back to try again without said logic: There have been a few false positives over the past few years (where the warning was triggered e.g. because Defender was still accessing a file that Git wanted to overwrite), and the fall-back logic seems to have helped occasionally in such situations. Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
ReFS is an alternative filesystem to NTFS. On Windows 2022, it seems not to support the rename operation using POSIX semantics that Git uses on Windows as of 391bcea (compat/mingw: support POSIX semantics for atomic renames, 2024-10-27). However, Windows 2022 reports `ERROR_NOT_SUPPORTED` in this instance. This is in contrast to `ERROR_INVALID_PARAMETER` (as previous Windows versions would report that do not support POSIX semantics in renames at all). Let's handle both errors the same: by falling back to the best-effort option, namely to rename without POSIX semantics. This fixes git-for-windows#5427 Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
It was reported to the Git for Windows project that a simple `git init` fails on Windows Server 2016: D:\Dev\test> git init error: could not write config file D:/Dev/test/.git/config: Function not implemented fatal: could not set 'core.repositoryformatversion' to '0' According to https://endoflife.date/windows-server, Windows Server 2016 is officially supported for another one-and-a-half years as of time of writing, so this is not good. The culprit is the `mingw_rename()` changes that try to use POSIX semantics when available, but fail to fall back properly on Windows Server 2016. This fixes git-for-windows#5695. Signed-off-by: Johannes Schindelin <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
"git for-each-ref" learns "--start-after" option to help applications that want to page its output. * kn/for-each-ref-skip: ref-cache: set prefix_state when seeking for-each-ref: introduce a '--start-after' option ref-filter: remove unnecessary else clause refs: selectively set prefix in the seek functions ref-cache: remove unused function 'find_ref_entry()' refs: expose `ref_iterator` via 'refs.h'
Redefine where the multi-pack-index sits in the object subsystem, which recently was restructured to allow multiple backends that support a single object source that belongs to one repository. A midx does span mulitple "object sources". * ps/object-store-midx: midx: remove now-unused linked list of multi-pack indices packfile: stop using linked MIDX list in `get_all_packs()` packfile: stop using linked MIDX list in `find_pack_entry()` packfile: refactor `get_multi_pack_index()` to work on sources midx: stop using linked list when closing MIDX packfile: refactor `prepare_packed_git_one()` to work on sources midx: start tracking per object database source
"git rebase -i" with bogus rebase.instructionFormat configuration failed to produce the todo file after recording the state files, leading to confused "git status"; this has been corrected. * ow/rebase-verify-insn-fmt-before-initializing-state: rebase: write script before initializing state
A few file descriptors left unclosed upon program completion in a few test helper programs are now closed. * hl/test-helper-fd-close: test-delta: close output descriptor after use test-delta: use strbufs to hold input files test-delta: handle errors with die() t/helper/test-truncate: close file descriptor after truncation
Revert back to “Git's” which was used before d30c5cc (doc: convert git-mergetool options to new synopsis style, 2025-05-25) accidentally changed it. Signed-off-by: Kristoffer Haugsbakk <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
"git cmd --help-all" now works outside repositories. * dk/help-all: builtin: also setup gently for --help-all parse-options: refactor flags for usage_with_options_internal
"git diff-tree" learned "--max-depth" option. * tc/diff-tree-max-depth: diff: teach tree-diff a max-depth parameter within_depth: fix return for empty path combine-diff: zero memory used for callback filepairs
Doc lint updates to encourage the newer and easier-to-use `synopsis` format, with fixes to a handful of existing uses. * ja/doc-lint-sections-and-synopsis: doc lint: check that synopsis manpages have synopsis inlines doc:git-for-each-ref: fix styling and typos doc: check for absence of the form --[no-]parameter doc: check for absence of multiple terms in each entry of desc list doc: check well-formedness of delimited sections doc: test linkgit macros for well-formedness
Test clean-up. * dk/t7005-editor-updates: t7005: sanitize test environment for subsequent tests t7005: stop abusing --exec-path t7005: use modern test style
Docfix. * ds/doc-count-objects-fix: count-objects: document count-objects pack
Remove dependency on the_repository and other globals from the commit-graph code, and other changes unrelated to de-globaling. * ps/commit-graph-wo-globals: commit-graph: stop passing in redundant repository commit-graph: stop using `the_repository` commit-graph: stop using `the_hash_algo` commit-graph: refactor `parse_commit_graph()` to take a repository commit-graph: store the hash algorithm instead of its length commit-graph: stop using `the_hash_algo` via macros
A new subcommand "git repo" gives users a way to grab various repository characteristics. * lo/repo-info: repo: add the --format flag repo: add the field layout.shallow repo: add the field layout.bare repo: add the field references.format repo: declare the repo command
Signed-off-by: Junio C Hamano <[email protected]>
Using one of the start_delayed_*() functions, clients of the progress API can request that a progress meter is only shown after some time. To do that, the implementation intends to count down the number of seconds stored in struct progress by observing flag progress_update, which the timer interrupt handler sets when a second has elapsed. This works during the first second of the delay. But the code forgets to reset the flag to zero, so that subsequent calls of display_progress() think that another second has elapsed and decrease the count again until zero is reached. Due to the frequency of the calls, this happens without an observable delay in practice, so that the effective delay is always just one second. This bug has been with us since the inception of the feature. Despite having been touched on various occasions, such as 8aade10 (progress: simplify "delayed" progress API), 9c5951c (progress: drop delay-threshold code), and 44a4693 (progress: create GIT_PROGRESS_DELAY), the short delay went unnoticed. Copy the flag state into a local variable and reset the global flag right away so that we can detect the next clock tick correctly. Since we have not had any complaints that the delay of one second is too short nor that GIT_PROGRESS_DELAY is ignored, people seem to be comfortable with the status quo. Therefore, set the default to 1 to keep the current behavior. Signed-off-by: Johannes Sixt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
The compatibility object format is only implemented for loose objects, not packed objects, so anyone attempting to push or fetch data into a repository with this option will likely not see it work as expected. In addition, the underlying storage of loose object mapping is likely to change because the current format is inefficient and does not handle important mapping information such as that of submodules. It would have been preferable to initially document that this was not yet ready for prime time, but we did not do so. We hinted at the fact that this functionality is incomplete in the description, but did not say so explicitly. Let's do so now: indicate that this feature is incomplete and subject to change and that the option is not designed to be used by end users. Signed-off-by: brian m. carlson <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
Documentation for "git rebase" has been updated. * je/doc-rebase: doc: git-rebase: update discussion of internals doc: git-rebase: move --onto explanation down doc: git rebase: clarify arguments syntax doc: git rebase: dedup merge conflict discussion doc: git-rebase: start with an example
The start_delayed_progress() function in the progress eye-candy API did not clear its internal state, making an initial delay value larger than 1 second ineffective, which has been corrected. * js/progress-delay-fix: progress: pay attention to (customized) delay time
"git log -L..." compared trees of multiple parents with the tree of the merge result in an unnecessarily inefficient way. * sg/line-log-merge-optim: line-log: simplify condition checking for merge commits line-log: initialize diff queue in process_ranges_ordinary_commit() line-log: get rid of the parents array in process_ranges_merge_commit() line-log: avoid unnecessary tree diffs when processing merge commits
Under a race against another process that is repacking the repository, especially a partially cloned one, "git fetch" may mistakenly think some objects we do have are missing, which has been corrected. * jk/fetch-check-graph-objects-fix: fetch-pack: re-scan when double-checking graph objects
The compatObjectFormat extension is used to hide an incomplete feature that is not yet usable for any purpose other than developing the feature further. Document it as such to discourage its use by mere mortals. * bc/doc-compat-object-format-not-working: docs: note that extensions.compatobjectformat is incomplete
Signed-off-by: Junio C Hamano <[email protected]>
Test fix. * ad/t1517-short-help-tests-fix: t/t1517: mark tests that fail with GIT_TEST_INSTALLED
Code clean-ups. * ps/reftable-libgit2-cleanup: refs/reftable: always reload stacks when creating lock reftable: don't second-guess errors from flock interface reftable/stack: handle outdated stacks when compacting reftable/stack: allow passing flags to `reftable_stack_add()` reftable/stack: fix compiler warning due to missing braces reftable/stack: reorder code to avoid forward declarations reftable/writer: drop Git-specific `QSORT()` macro reftable/writer: fix type used for number of records
Discord has been added to the first contribution documentation as another way to ask for help. * ds/doc-community-discord: doc: add discord to ways of getting help
"git fetch" can clobber a symref that is dangling when the remote-tracking HEAD is set to auto update, which has been corrected. * jk/no-clobber-dangling-symref-with-fetch: refs: do not clobber dangling symrefs t5510: prefer "git -C" to subshell for followRemoteHEAD tests t5510: stop changing top-level working directory t5510: make confusing config cleanup more explicit
"git describe <blob>" misbehaves and/or crashes in some corner cases, which has been taught to exit with failure gracefully. * jk/describe-blob: describe: pass commit to describe_commit() describe: handle blob traversal with no commits describe: catch unborn branch in describe_blob() describe: error if blob not found describe: pass oid struct by const pointer
Manual page for "gitk" is updated with the current maintainer's name. * js/doc-gitk-history: doc/gitk: update reference to the external project
Signed-off-by: Junio C Hamano <[email protected]>
Doc mark-up fix. * ja/asciidoc-doctor-verbatim-fixes: doc: fix asciidoc format compatibility in pretty-formats.adoc
Fix missing single-quote pairs in a documentation page. * kh/doc-interpret-trailers-markup-fix: doc: interpret-trailers: close all pairs of single quotes
Documentation typofix. * kh/doc-config-typofix: doc: config: replace backtick with apostrophe for possessive
Doc update. * js/doc-sending-patch-via-thunderbird: doc/format-patch: adjust Thunderbird MUA hint to new add-on
Update the instruction to use of GGG in the MyFirstContribution document to say that a GitHub PR could be made against `git/git` instead of `gitgitgadget/git`. * ds/doc-ggg-pr-fork-clarify: doc: clarify which remotes can be used with GitGitGadget
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.