w4kpm
commented
2 years ago In some cases, we may have the need to have two different github repositories - repository A on the remote box and repository B on the local box. If this is the case any file that has been committed to repository A will not be on the repository B and vise versa.
When using the file sync tool to pull files across, we could possibly check repository B for any sha that is listed on the file_data, if it is not found in the local (repositoryB), then we treat it as a brand new file and just clear ou tthe sha when we add it to the database. Later when we do a local github sync, it will go ahead and add this file because it just adds all files without a sha listed.
An alternate idea is to always check the sha that comes across from a synced file (i.e. transferred from a remote box) to verify that the sha is in our github repository - if it is not, then we blank out the sha locally so that the next time we sync, then we also add that file to our local repository.
cullerton
Currently, when syncing files between two systems, we assume that both of these systems are using the same github repository with different branches.
In the future, we may want to sync a local box with a remote server but have a completely different github repository set up for tracking local changes. If we pull over a file from a remote server, and it has a sha built into it, then we wouldn't build a new object for that file and assume it is already in the github object database,
This would in turn create a problem when we build the trees for the commit.
If instead we never transfer a sha for a new file from a remote file if this option is turned on, then it will always create a new object for our local github repository.