Tags: mstrap/git
Tags
update-index: refresh should rewrite index in case of racy timestamps 'git update-index --refresh' and '--really-refresh' should force writing of the index file if racy timestamps have been encountered, as 'git status' already does [1]. Note that calling 'git update-index --refresh' still does not guarantee that there will be no more racy timestamps afterwards (the same holds true for 'git status'): - calling 'git update-index --refresh' immediately after touching and adding a file may still leave racy timestamps if all three operations occur within the racy-tolerance (usually 1 second unless USE_NSEC has been defined) - calling 'git update-index --refresh' for timestamps which are set into the future will leave them racy To guarantee that such racy timestamps will be resolved would require to wait until the system clock has passed beyond these timestamps and only then write the index file. Especially for future timestamps, this does not seem feasible because of possibly long delays/hangs. [1] https://lore.kernel.org/git/[email protected]/ Signed-off-by: Marc Strapetz <[email protected]>
update-index: refresh should rewrite index in case of racy timestamps 'git update-index --refresh' and '--really-refresh' should force writing of the index file if racy timestamps have been encountered, as 'git status' already does [1]. Note that calling 'git update-index --refresh' still does not guarantee that there will be no more racy timestamps afterwards (the same holds true for 'git status'): - calling 'git update-index --refresh' immediately after touching and adding a file may still leave racy timestamps if all three operations occur within the racy-tolerance (usually 1 second unless USE_NSEC has been defined) - calling 'git update-index --refresh' for timestamps which are set into the future will leave them racy To guarantee that such racy timestamps will be resolved would require to wait until the system clock has passed beyond these timestamps and only then write the index file. Especially for future timestamps, this does not seem feasible because of possibly long delays/hangs. [1] https://lore.kernel.org/git/[email protected]/ Signed-off-by: Marc Strapetz <[email protected]>
update-index: refresh should rewrite index in case of racy timestamps 'git update-index --refresh' and '--really-refresh' should force writing of the index file if racy timestamps have been encountered, as 'git status' already does [1]. Note that calling 'git update-index --refresh' still does not guarantee that there will be no more racy timestamps afterwards (the same holds true for 'git status'): - calling 'git update-index --refresh' immediately after touching and adding a file may still leave racy timestamps if all three operations occur within the racy-tolerance (usually 1 second unless USE_NSEC has been defined) - calling 'git update-index --refresh' for timestamps which are set into the future will leave them racy To guarantee that such racy timestamps will be resolved would require to wait until the system clock has passed beyond these timestamps and only then write the index file. Especially for future timestamps, this does not seem feasible because of possibly long delays/hangs. [1] https://lore.kernel.org/git/[email protected]/ Signed-off-by: Marc Strapetz <[email protected]>
Two small 'git repack' fixes I was experimenting with some ideas in 'git repack' and discovered these two bugs. The first is a "real" bug in that it repacks much more data than is necessary when repacking with '--write-midx -b' and there exists a .keep pack. The fix is simple, which is to change a condition that was added for the '-b' case before '--write-midx' existed. The second is a UX bug in that '--quiet' did not disable all progress, at least when stderr was interactive. Thanks, -Stolee Derrick Stolee (2): repack: respect kept objects with '--write-midx -b' repack: make '--quiet' disable progress builtin/repack.c | 8 +++++--- t/t7700-repack.sh | 15 +++++++++++++++ 2 files changed, 20 insertions(+), 3 deletions(-) base-commit: 69a9c10 Submitted-As: https://lore.kernel.org/git/[email protected]
normalize format of yes/no prompts Changes since v2: * Moves question mark before the yes/no choices, to be more consistent with other tools. * Normalizes format string for bisect--helper, clean, add-patch. * Updates localized versions of all changed strings, which was missed in v2. Kashav Madan (4): bisect--helper: normalize format string of yes/no prompts clean: normalize format string of yes/no prompt add-patch: normalize format string of yes/no prompt help: make auto-correction prompt more consistent add-patch.c | 4 ++-- builtin/bisect--helper.c | 6 +++--- builtin/clean.c | 2 +- help.c | 2 +- po/bg.po | 14 +++++++------- po/ca.po | 20 ++++++++++---------- po/de.po | 20 ++++++++++---------- po/el.po | 14 +++++++------- po/es.po | 22 +++++++++++----------- po/fr.po | 20 ++++++++++---------- po/git.pot | 10 +++++----- po/id.po | 18 +++++++++--------- po/it.po | 14 +++++++------- po/ko.po | 16 ++++++++-------- po/pl.po | 20 ++++++++++---------- po/pt_PT.po | 16 ++++++++-------- po/ru.po | 16 ++++++++-------- po/sv.po | 22 +++++++++++----------- po/tr.po | 20 ++++++++++---------- po/vi.po | 20 ++++++++++---------- po/zh_CN.po | 20 ++++++++++---------- po/zh_TW.po | 20 ++++++++++---------- 22 files changed, 168 insertions(+), 168 deletions(-) base-commit: e773545 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]
strlcpy(): safer and faster version From: Andrii Makukha <[email protected]> Original strlcpy() has a significant disadvantage of being both unsafe and inefficient. It unnecessarily calculates length of `src` which may result in a segmentation fault if `src` is not terminated with a NUL-character. In this fix, if `src` is too long, strlcpy() returns `size`. This allows to still detect an error while fixing the mentioned vulnerabilities. It deviates from original strlcpy(), but for a good reason. Signed-off-by: Andrii Makukha <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
fast-export: fix surprising behavior with --first-parent From: William Sprent <[email protected]> The revision traversal machinery typically processes and returns all children before any parent. fast-export needs to operate in the reverse fashion, handling parents before any of their children in order to build up the history starting from the root commit(s). This would be a clear case where we could just use the revision traversal machinery's "reverse" option to achieve this desired affect. However, this wasn't what the code did. It added its own array for queuing. The obvious hand-rolled solution would be to just push all the commits into the array and then traverse afterwards, but it didn't quite do that either. It instead attempted to process anything it could as soon as it could, and once it could, check whether it could process anything that had been queued. As far as I can tell, this was an effort to save a little memory in the case of multiple root commits since it could process some commits before queueing all of them. This involved some helper functions named has_unshown_parent() and handle_tail(). For typical invocations of fast-export, this alternative essentially amounted to a hand-rolled method of reversing the commits -- it was a bunch of work to duplicate the revision traversal machinery's "reverse" option. This hand-rolled reversing mechanism is actually somewhat difficult to reason about. It takes some time to figure out how it ensures in normal cases that it will actually process all traversed commits (rather than just dropping some and not printing anything for them). And it turns out there are some cases where the code does drop commits without handling them, and not even printing an error or warning for the user. Due to the has_unshown_parent() checks, some commits could be left in the array at the end of the "while...get_revision()" loop which would be unprocessed. This could be triggered for example with git fast-export main -- --first-parent or non-sensical traversal rules such as git fast-export main -- --grep=Merge --invert-grep While most traversals that don't include all parents should likely trigger errors in fast-export (or at least require being used in combination with --reference-excluded-parents), the --first-parent traversal is at least reasonable and it'd be nice if it didn't just drop commits. It'd also be nice for future readers of the code to have a simpler "reverse traversal" mechanism. Use the "reverse" option of the revision traversal machinery to achieve both. Even for the non-sensical traversal flags like the --grep one above, this would be an improvement. For example, in that case, the code previously would have silently truncated history to only those commits that do not have an ancestor containing "Merge" in their commit message. After this code change, that case would include all commits without "Merge" in their commit message -- but any commit that previously had a "Merge"-mentioning parent would lose that parent (likely resulting in many new root commits). While the new behavior is still odd, it is at least understandable given that --reference-excluded-parents is not the default. 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] In-Reply-To: https://lore.kernel.org/git/[email protected]
sparse-checkout: fix segfault on malformed patterns This series fixes some issues with parsing sparse-checkout patterns when core.sparseCheckoutCone is enabled but the sparse-checkout file itself contains patterns that don't match the cone mode format. The first patch fixes a segfault first reported in [1]. The other two patches are from an earlier submission [2] that never got picked up and I lost track of. There was another patch involving 'git sparse-checkout init --cone' that isn't necessary, especially with Elijah doing some work in that space right now. [1] git-for-windows#3498 [2] https://lore.kernel.org/git/[email protected] Thanks, -Stolee Update in v4 ============ * For added precaution, this kind of unexpected duplicate pattern will disable cone mode matching. * Tests are updated to verify this new behavior. Updates in v2 and v3 ==================== * I intended to fix a typo in a patch, but accidentally sent the amend! commit in v2 * v3 has the typo fix properly squashed in. * Added Elijah's review. Derrick Stolee (3): sparse-checkout: fix segfault on malformed patterns sparse-checkout: fix OOM error with mixed patterns sparse-checkout: refuse to add to bad patterns builtin/sparse-checkout.c | 5 +++- dir.c | 6 ++--- t/t1091-sparse-checkout-builtin.sh | 37 +++++++++++++++++++++++++++++- 3 files changed, 42 insertions(+), 6 deletions(-) base-commit: abe6bb3 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]
help: make auto-correction prompt more consistent From: Kashav Madan <[email protected]> There are three callsites of git_prompt() that ask the user for "yes/no" confirmation, but the one in help.c, used for auto-correction, is formatted differently from the others. This updates that format string to make the prompt look more consistent. Signed-off-by: Kashav Madan <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected] In-Reply-To: https://lore.kernel.org/git/[email protected]
help: add space after autocorrect prompt From: Kashav Madan <[email protected]> Signed-off-by: Kashav Madan <[email protected]> Submitted-As: https://lore.kernel.org/git/[email protected]
PreviousNext