Assume a non-version controlled project directory with sub-directories (A). A year later, that directory is COPIED and further development occurs (A').
I've just added the earlier version, A, to Git. In the spirit of version control I wish to copy A' files over A files (after all, they are the same project), but I seek to systematically delete A files that are no longer present in the later A' version.
I've Googled for quite some time but can't seem to find the best practice for this situation that (I bet) occurs frequently so I'm hoping there is a well-known "recipe" for how to pull it off without writing custom code.
Is it possible to use git-diff --diff-filter=D ("Deleted") to generate rm's so that the "residue" of A longer resides in source control?
So if A and A' are just two different directories with different version of code and you are creating a brand new git repo, then this is actually pretty easy.
Since you've already got your git repo setup with the A files, all you need to do is delete everything in your repo's directory (except, of course, for any git files/folders) and then copy the files from A', then add a new commit.
So, your git history would look something like this:
z9y8x7w6v current state (A')
a1b2c3d4e f1rst p0st (A)
You'll be able to compare changes between A and A', but any new work will be starting off with A'. This will just ensure that you have A as an old artifact in your git history.
Side Note: It's good that you are thinking about this now. If you had waited, and any work had been done off of A' in the repo, then slotting A into the history would have been extremely difficult.