On 5/10/2018 6:31 PM, Elijah Newren wrote:
Hi Ben,
On Thu, May 10, 2018 at 12:09 PM, Ben Peart wrote:
On 5/10/2018 12:19 PM, Elijah Newren wrote:
On Thu, May 10, 2018 at 7:16 AM, Ben Peart
wrote:
Given the example perf impact is arbitrary
Ben Peart writes:
> Documentation/config.txt | 10
> Documentation/git-status.txt | 10
> builtin/commit.c | 41
> diff.c | 2 +-
> diff.h | 1 +
> t/t7525-status-rename.sh | 90
Elijah Newren writes:
>> Note: I removed the --no-breaks command line option from the original patch
>> as
>> it will no longer be needed once the default has been changed [1] to turn it
>> off.
>>
>> [1]
>>
Hi Ben,
On Thu, May 10, 2018 at 12:09 PM, Ben Peart wrote:
> On 5/10/2018 12:19 PM, Elijah Newren wrote:
>> On Thu, May 10, 2018 at 7:16 AM, Ben Peart
>> wrote:
> Given the example perf impact is arbitrary (the actual example that
> triggered this
On 5/10/2018 12:19 PM, Elijah Newren wrote:
Hi Ben,
On Thu, May 10, 2018 at 7:16 AM, Ben Peart wrote:
After performing a merge that has conflicts, git status will by default attempt
to detect renames which causes many objects to be examined. In a virtualized
repo,
Hi Ben,
On Thu, May 10, 2018 at 7:16 AM, Ben Peart wrote:
> After performing a merge that has conflicts, git status will by default
> attempt
> to detect renames which causes many objects to be examined. In a virtualized
> repo, those objects do not exist locally so
After performing a merge that has conflicts, git status will by default attempt
to detect renames which causes many objects to be examined. In a virtualized
repo, those objects do not exist locally so the rename logic triggers them to be
fetched from the server. This results in the status call
7 matches
Mail list logo