Tags: Aetotvl6789/git
Tags
win32: close handles of threads that have been joined After joining threads, the handle to the original thread should be closed as it no longer needs to be open. Signed-off-by: Seija Kijin [email protected] Seija Kijin (2): win32: prepare pthread.c for change by formatting win32: close handles of threads that have been joined compat/win32/pthread.c | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) base-commit: 4dbebc3 Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
run-command: make async_exit usage consistent From: Seija Kijin <[email protected]> Use async_exit instead of pthread_exit, and make async_exit inline. Functions were reordered so that this would compile. Luckily, the order remains consistent. Signed-off-by: Seija Kijin <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
win32: close handles of threads that have been joined After joining threads, the handle to the original thread should be closed as it no longer needs to be open. Signed-off-by: Seija Kijin [email protected] Seija Kijin (2): win32: prepare pthread.c for change by formatting win32: close handles of threads that have been joined compat/win32/pthread.c | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) base-commit: 2b4f5a4 Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
git: edit variable types to match what is assigned to them From: Seija Kijin <[email protected]> There are many places where "int len = strlen(foo);" is written, just for len to be passed as a parameter of size_t. This causes truncation and then expansion back from int to size_t. This is poor logic. Signed-off-by: Seija Kijin <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
ci(github): restore "print test failures" step name From: Phillip Wood <[email protected]> As well as removing the explicit shell setting d8b21a0 (CI: don't explicitly pick "bash" shell outside of Windows, fix regression, 2022-12-07) also reverted the name of the print test failures step introduced by 5aeb145 (ci(github): bring back the 'print test failures' step, 2022-06-08). This is unfortunate as 5aeb145 added a message to direct contributors to the "print test failures" step when a test fails and that step is no-longer known by that name on the non-windows ci jobs. In principle we could update the message to print the correct name for the step but then we'd have to deal with having two different names for the same step on different jobs. It is simpler for the implementation and contributors to use the same name for this step on all jobs. Signed-off-by: Phillip Wood <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
dir: check for single file cone patterns From: William Sprent <[email protected]> The sparse checkout documentation states that the cone mode pattern set is limited to patterns that either recursively include directories or patterns that match all files in a directory. In the sparse checkout file, the former manifest in the form: /A/B/C/ while the latter become a pair of patterns either in the form: /A/B/ !/A/B/*/ or in the special case of matching the toplevel files: /* !/*/ The 'add_pattern_to_hashsets()' function contains checks which serve to disable cone-mode when non-cone patterns are encountered. However, these do not catch when the pattern list attempts to match a single file or directory, e.g. a pattern in the form: /A/B/C This causes sparse-checkout to exhibit unexpected behaviour when such a pattern is in the sparse-checkout file and cone mode is enabled. Concretely, with the pattern like the above, sparse-checkout, in non-cone mode, will only include the directory or file located at '/A/B/C'. However, with cone mode enabled, sparse-checkout will instead just manifest the toplevel files but not any file located at '/A/B/C'. Relatedly, issues occur when supplying the same kind of filter when partial cloning with '--filter=sparse:oid=<oid>'. 'upload-pack' will correctly just include the objects that match the non-cone pattern matching. Which means that checking out the newly cloned repo with the same filter, but with cone mode enabled, fails due to missing objects. To fix these issues, add a cone mode pattern check that asserts that every pattern is either a directory match or the pattern '/*'. Add a test to verify the new pattern check and modify another to reflect that non-directory patterns are caught earlier. Signed-off-by: William Sprent <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
win32: remove return_0 inline function From: Seija Kijin <[email protected]> The macro works on its own without the helper function Signed-off-by: Seija Kijin <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
grep: simplify is_empty_line From: Seija Kijin <[email protected]> Signed-off-by: Seija Kijin <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
grep: simplify is_empty_line From: Seija Kijin <[email protected]> Signed-off-by: Seija Kijin <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
git: edit variable types to match what is assigned to them From: Seija Kijin <[email protected]> There are many places where "int len = strlen(foo);" is written, just for len to be passed as a parameter of size_t. This causes truncation and then expansion back from int to size_t. This is poor logic. Signed-off-by: Seija Kijin <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
PreviousNext