Vault transcript reorg – verification (why 429k “deletions” is not data loss)
Why the diff shows 429,296 deletions
Git compares main to the vault reorg branch by path. For each file:
- On main: the file lives at
knowledge/clients/unassigned/transcripts/<name>.md. - On the reorg branch: the same file lives at
knowledge/clients/<client>/transcripts/<name>.md.
So the diff sees “this path was removed” and counts all those lines as deletions, and “this path was added” as insertions. Rename detection matches many of these (they show as renames with 0 insertions/0 deletions), but 324 files are still reported as “deletion only” because Git doesn’t pair them as renames in the cross-branch diff (e.g. merge/base differences). Those 324 files account for the 429,296 deleted lines in the stat.
So the big number is lines removed from the old paths, not content thrown away.
Verification: content is moved, not lost
Check run on the vault reorg branch:
- For every file that appears as “deletion only” (old path removed), the same filename was looked up under
knowledge/clients/*/transcripts/(excluding unassigned). - 319 of those 324 files are present under a client (or GTM) folder with the same content (moved).
- 4 files are same meeting, different transcript ID (newer version in the client folder; old ID removed).
- 1 file was not in the move plan and is not under any client folder:
2024-06-21_intro-to-snowflake_fb51471e.md(1,464 lines).
That one was in “Skipped (no match)” in_AUTO_MOVE_PLAN.mdand was removed from unassigned without a new location. It has been restored toknowledge/clients/unassigned/transcripts/on the reorg branch so it is not lost.
Summary
| What the diff shows | What it means |
|---|---|
| 429,296 deletions | Lines no longer at old paths (unassigned/transcripts/) |
| 683 insertions | New paths + a few net-new transcripts |
| 401 renames (R100) | Same content, detected as rename |
| 324 “deletion-only” | Same content at new path; Git didn’t pair as rename in this diff |
Bottom line: The 429k is from moving transcripts to client folders, not from deleting content. One file (intro-to-snowflake) was restored; the rest of the “deleted” content exists under the new client paths.