[FEATURE] Age-based filtering: surface only repos dirty/unpushed for longer than N days

[nilp0inter]

What problem does this solve?

The signal-to-noise problem when scanning all your repos: any project you are actively working on is almost always dirty or ahead of upstream. That state is normal, expected, and not actionable. The repos you actually want to be warned about are the ones you touched, left dirty/unpushed, and then forgot — which is precisely the README's "Find old repos you forgot to commit/push" and "know which repos still have unpushed commits before you leave for the day" use cases.

Today the only filters are state-based (dirty|uncommitted|unpushed|...). So a daily or login-time reposcan run buries the one genuinely-forgotten repo among a dozen actively-edited ones, and you quickly learn to ignore the output — which defeats the purpose of running it on a schedule.

Concrete motivation: I want to wire reposcan into a shell login hook / periodic notification, but only want it to speak up about repos that have been sitting dirty or unpushed for more than, say, a week. There is currently no way to express "old and dirty".

Proposed solution

Add an age dimension based on how long the repo has been in its current at-risk state:

• Add LastModified time.Time (JSON lastModified) to report.RepoState. Cheapest network-free signals: newest mtime among git status --porcelain entries for the uncommitted case, and git log -1 --format=%cI (tip commit date) for the unpushed case.
• Add a --stale-days N flag (config staleDays) that, when > 0, keeps only repos whose relevant state is older than N days.
• Compose with --filter: e.g. reposcan -f uncommitted --stale-days 7 = "uncommitted changes I haven't touched in a week", reposcan -f unpushed --stale-days 14 = "commits I've been sitting on for two weeks".

This turns reposcan from "list everything dirty right now" into "list what I've forgotten", which is the higher-value framing for automation (cron, login hooks, status bars) and keeps always-dirty active projects quiet.

Additional context

The exact semantics of "age" per state are a design choice (mtime vs commit date vs reflog) — happy to discuss the approach in the issue before coding. Glad to write the PR (report field + flag/config + filter composition + tests) if you'd take it.

[mabd-dev]

Great suggestion. I fully agree, this is needed

Few things need discussion before we start implementing

Age semantics

As you mentioned we have 3 sources: mtime, commit date and reflog

• mtime: useful to know when a file last changed
• commit date: get last commit date
• reflog: last branch switch, rebase, fetch....

I would ditch reflog for now. Changing a branch, pulling, pushing, merging or even deleting a branch does not mean I am working on the repo. I could switch a branch on an old project just to see how I did something, but that does not mean I am working on that project.

mtime and commit date each describe a different state. I would go to using both (if possible). Get last file changed (using git status --porcelain) and last commit date then take the max between both. If a repo does not have any file changed (git status return nothing) then use last commit date. If repo does not have any commit, then take last file change.

Filters

filter	age is useful
all	✅
dirty	✅
uncommited	✅
unpushed	✅
unpulled	❌
stash	❌

unpulled and stash don't have the same last touched signal like uncommited and pushed. Right ? What do you think ?

When to calculate age

Only when stale-days flag/config value is greater than 0. This means we need to send stale-days value to GetGitRepoStatesConcurrent and when value > 0 calculate lastModified else just put a very old date

Other option is to always calculate lastModified but I don't see a point of this, if we don't show it on UI nor filter by it. Extra work for nothing. Unless we add it as a new column in repos table, that would be nice actually.
If that is the case, let's make that column show/hide based on config value (check #49)

Repo with lot of file changes

I guess this should be fine since we are using go-routines and launching multiple workers. But we need to verify

Happy to hear your thoughts on this

[nilp0inter]

Good distinction — agree they shouldn't be lumped together.

Unpulled: convinced. Skip the stale filter for unpulled in v1. The signal there is remote-state ("commits accumulated I haven't pulled"), not local intent — a repo I work on daily is unpulled the moment a colleague pushes, and fast-moving upstreams like nixpkgs would always be unpulled. Filtering it by my activity doesn't answer "did I forget." If there's later demand for "branches behind upstream for >N days," that's a separate age (upstream-ref commit date) — happy to file a follow-up.

Stash: include, but properly. A 2-year-old stash in a repo I've otherwise worked on yesterday is the forgot-this case, but bare LastActivity = max(mtime, HEAD-date) would mark that repo as fresh and hide it — the wrong answer. So I'd extend LastActivity to max(porcelain-mtime, HEAD-commit-date, newest-stash-time), one extra git stash list --format=%ci | head -1 per repo, gated on staleDays > 0. All three sources are "things I did to this repo," which keeps the semantics coherent.

Updated filter table for v1:

filter	stale applies
all	✅
dirty	✅
uncommitted	✅
unpushed	✅
unpulled	❌ (remote-state signal; possible follow-up)
stash	✅ (requires stash-time in LastActivity)

OK to proceed on this basis?

[mabd-dev]

I got your point.

I guess we have a bigger issue here unrelated to this feature request. In the example you gave: a fast-moving upstream like nixpkgs would always be unpulled
This is a core problem, because these repos will also be considered noisy and the only thing you can do is pull.

Regarding this feature request, you are ok to proceed with your suggestion. I will have to think above the above case deeper