add a test to ensure cache key is same even if renormalized #967
Conversation
| { | ||
| // Perform whatever action is required in your scenario. | ||
| System.IO.FileInfo fi = new System.IO.FileInfo(file); | ||
| result.Add(fi.Name); |
There was a problem hiding this comment.
You are just using the name of the file. Even if it is modified by normalization, this shouldn't change. What happens if you use the contents of the file?
There was a problem hiding this comment.
You are right. I'm just using the name - and we could pull in the contents as well to be more precise. Though I think normalization is just bringing in the branches from origin. I could go with using the contents though.
I made the change in the next commit. The only thing is now we are opening a lot of files, and File I/O is always slooooow.
|
@rubenmamo Hi Ruben, can you confirm that these changes work in your scenario? Thanks so much. |
|
We should probably have a 3.6.2 release right? I have created support/3.6.0 to allow us to fix issues in the 3.6.x version. Can you re-target this PR to that branch? |
|
|
|
@JakeGinnivan can i re-target the PR from this PR or do I need to make a new PR? |
|
isaacs/github#18 sigh Update. Sorry guys, I'm going to need a git lesson. Do I cherry pick the changes onto support/3.6.0? Is there a way to rebase on an older branch my changes? |
…fy cache factory to traverse refs directory instead of just looking at the timestamp (which changes if renormalized)
|
@totufim, apologies for not replying earlier. I wasn't in the office and couldn't check with the latest version. Dynamic repositories are not working in 3.6.1 and I suspect this would be the same for 3.6.2. The new issue is not caused by this change. I have created issue #981 which details the new issue. |
Re: #942
If the gitPreparer normalize (in Initialize) is called multiple times, the cachekey will change each time, even though .git/refs has exactly the same content. This is because the cachekey is based on the timestamp rather than the contents. This PR changes the cachekey calculation so that it computes a hash based on the filenames and directory names in .git/refs.