Raised by a commenter during our Product Hunt launch, and it's a real gap worth designing for.
The scenario
A developer leaves a company and loses access to the repos where years of their best work lives. The CLI reads local git history, so once the repo is gone from their machine there is nothing left to scan. Today the honest answer is "scan while you still legitimately have the repo", but nothing in the product helps you realize that before it's too late.
The constraint
Any solution has to respect the existing boundaries: scanning stays local, nothing leaves the machine except the bounded bundle, and the scan's authorization confirmation stays meaningful. "Just keep a copy of the employer's repo forever" is not advice we can give.
Open questions
- Is this a documentation problem (an offboarding guide: "changing jobs? scan before you hand back the laptop"), a product problem (some kind of reminder or checklist), or both?
- Is there any honest way to strengthen evidence captured long ago (e.g. the bundle already carries first/last seen dates and signed-commit ratios; does "scanned while employed there" deserve any explicit representation)?
- What should NOT be built here? (Anything that encourages retaining code you shouldn't retain is out.)
Ideas welcome. This came from the community and the best answer probably will too.
Raised by a commenter during our Product Hunt launch, and it's a real gap worth designing for.
The scenario
A developer leaves a company and loses access to the repos where years of their best work lives. The CLI reads local git history, so once the repo is gone from their machine there is nothing left to scan. Today the honest answer is "scan while you still legitimately have the repo", but nothing in the product helps you realize that before it's too late.
The constraint
Any solution has to respect the existing boundaries: scanning stays local, nothing leaves the machine except the bounded bundle, and the scan's authorization confirmation stays meaningful. "Just keep a copy of the employer's repo forever" is not advice we can give.
Open questions
Ideas welcome. This came from the community and the best answer probably will too.