sparse-index diff integration: initial attempt #418
Closed
Conversation
This file contains 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
THIS CHANGE IS NOT IN FINAL FORM AND IS CURRENTLY JUST INTENDED FOR FEEDBACK. To understand the context laid out below I have purposefully included both source and test changes in this initial commit. Based on the feedback I get, I will either split this commit or create an entirely new branch with the necessary changes when it is ready to officially submit. This change enables running the `diff` builtin command without expanding the full index in a cone-mode sparse checkout. It is an attempt to add the basic infrastructure to "light up" sparse index for the command. However, based on some testing, this may need to change. After reviewing microsoft#417, I decided to add `ensure_full_index` to this initial commit in an attempt to maintain current behavior. However, as I started building and testing with and without this update, I noticed unexpected results. The `ensure_not_expanded` tests I added are passing with `ensure_full_index` both enabled and disabled. That felt wrong, so I used `TRACE2` to try and understand what was happening and have attached the results. It looks as though no code paths in `diff.c` are actually being used. On the bright side, however, it doesn't look as though `ensure_full_index` is ever being called. I recognize my lack of knowledge wrt `cache-tree` and `read-cache` may be the reason I'm unsure what the correct path forward is. In light of this, any guidance is appreciated.
|
Here are the |
ldennington
requested review from
vdye and
derrickstolee
and removed request for
derrickstolee and
vdye
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.
THIS CHANGE IS NOT IN FINAL FORM AND IS CURRENTLY JUST INTENDED FOR
FEEDBACK. To understand the context laid out below I have purposefully
included both source and test changes in this initial commit. Based on
the feedback I get, I will either split this commit or create
an entirely new branch with the necessary changes when it is ready to
officially submit.
This change enables running the
diffbuiltin command withoutexpanding the full index in a cone-mode sparse checkout. It is an attempt
to add the basic infrastructure to "light up" sparse index for the
command. However, based on some testing, this may need to change.
After reviewing #417, I decided to add
ensure_full_indexto thisinitial commit in an attempt to maintain current behavior. However,
as I started building and testing with and without this update, I
noticed unexpected results.
The
ensure_not_expandedtests I added are passing withensure_full_indexboth enabled and disabled. That felt wrong, so Iused
TRACE2to try and understand what was happening and have attachedthe results below.
It looks as though no code paths in
diff.care actually being used.On the bright side, however, it doesn't look as though
ensure_full_indexis ever being called. I recognize my lack of knowledge wrt
cache-treeand
read-cachemay be the reason I'm unsure what the correct pathforward is. In light of this, any guidance is appreciated.