Cap output from git at string max length#19724
Merged
niik merged 1 commit intodevelopmentfrom Dec 16, 2024
Merged
Conversation
Include operation name when maxBuffer is exceeded
✨
Merged
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
Description
This should make its way into dugite rather than living here in Desktop but adding it here for now to be able to incorporate it into a hotfix.
As part of the work to enable large git output I lifted the previous 1Mb limit on Git output (desktop/dugite#596) and set it to Infinity. The problem with that occurs when a Git command invoked with a string encoding spits out more than the maximum string length. I thought that in that case the error thrown would get picked up by
execFileand passed on into the error handler but it's not. Instead it gets thrown in an asynchronous callback that we can't catch (other than in the uncaughtException process handler).Instead we'll check if the encoding is a "readable encoding" (i.e. not resulting in a buffer) and set the max length to
kStringMaxLengthwhich is currently 536870888 bytes. Should a Git command spit out more than this Node will throw an exception which will end up in execFile's error callback and then we can handle it gracefully.I've also added some extra debugging here which will be useful for us going forward. By including the operation name in the execution message we should be able to figure out which operations are candidates for using buffer encoding.
Screenshots
Release notes
Notes: