Starting January 2026, Gmail is removing support for POP3 and Gmailify. This means millions of people who rely on Gmail to consolidate emails from other accounts will suddenly lose features like spam protection, inbox categories, and advanced search on their third-party emails.If you manage multiple email accounts, how are you planning to keep all your emails flowing smoothly to Gmail or...
Google is killing POP3/Gmailify in January 2026, breaking workflows for fetching email into Gmail.I built Forward My Inbox (https://forwardmyinbox.com) as a replacement: connects to your IMAP inbox and forwards new emails to Gmail while preserving threading, reply-to, and labels—no POP/Gmailify needed.Credentials are encrypted, headers are preserved, forwarding is instant. Looking for feedback...
It drives me crazy the amount of noise there is on all the PR ai code reviews. There is so much that could be caught by reviews before - maybe at commit time? Is this just me??
Ask HN,Code reviews are essential, but I keep seeing the same pattern: PR reviews are full of comments about trivial bugs, lint issues, and convention mismatches that could have been caught before the code ever left the developer’s machine.With AI-assisted coding becoming the norm, this seems worse, not better. AI is fast, but it happily produces subtle bugs, inconsistent patterns, and sloppy...
It feels increasingly backwards that PR reviews are where we catch basic bugs, style issues, and convention violations.
With AI writing a large chunk of code now, the volume of small, avoidable mistakes has gone up. Yet we still wait until PRs to point out things that could have been flagged instantly, pre-commit, on the author’s machine.
PR review should be about design, correctness, and tradeoffs — not “missing await”, inconsistent patterns, or obvious slop.
Is there a good reason pre-commit review isn’t the norm, or are we just accepting an inefficient workflow because it’s familiar?
Curious how others see this.
With more AI-written code, tests pass but logic issues still slip through. Would earlier, pre-commit code reviews make more sense?
I’m exploring this idea with a tool that reviews logic at commit time — curious how others think about timing reviews earlier.
Curious to hear what would actually help
I spent some time improving the CommitGuard landing page to make it clearer and more direct about what the tool does.
I’d love your honest feedback, does it make sense at a glance? Any suggestions for improvement?
Hi HN,I’m experimenting with commit-based code review as an alternative to PR-based review.Instead of analyzing large PR diffs, this reviews each commit incrementally, while context is still fresh. It’s fully configurable and intentionally low-noise, high signal - focused on catching issues that tend to slip through and compound over time.The goal isn’t to replace CI or PR review, but to move...
So I created this tool that runs on commit. It is easily configurable and bypassable.
Would love to hear what community thoughts are on this idea.
You can also add custom prompts, choose context option and severity.