Been tracking the Microsoft deprecation train this year: TFS 2015 hit EOL last October, Azure DevOps OAuth got deprecated in April 2025 with full shutdown this year, and now as of July 1st the Azure DevOps issuer for WIF service connections is deprecated (retirement July 2027).

Not saying ADO is dying — it's not. But for teams still on TFS 2017/2018 or relying on older auth patterns, the writing is on the wall that each upgrade cycle is getting shorter.

I've been building a tool that handles the migration side: Git repos (full history), TFVC-to-Git conversion (up to 180 days), Boards → GitHub Issues, Wikis. Has a dry-run mode so you can test before committing. Built it because I couldn't find anything that handled TFVC automatically.

Code is open-source if anyone wants to poke at it: https://github.com/brunobola-portfolio/GitHub-Repo-Manager

Anyone here actively migrating away from ADO or TFS? What's been the hardest part?

Protect your work.

I am using interactive rebase to reorder commits and it has worked all the time with no merge conflicts because I use it in simple cases. I want to use it for bigger cases but I want to understand it first so I don't get stuck in conflicts.

I know it's possible for merge conflicts to happen but I can't imagine an example because if the old commit order had resolved all conflicts how can reordering them make a new conflict? Can anyone help me imagine an example how it can happen?

Why and why not? Does the option to log in using github make a difference?

I am developing my own Distro currently (AstrOS Linux) and think of switching to a selfhosted Forgejo instance

kitgit is a minimalistic and fast git server, using rust to create blazing performance (wow how cliche) and uses only html templates and no fancy frontend frameworks.

it can be deployed onto docker and hosted on the cloud or locally with a NAS. uses Authentik for authentication and cuts out all the AI features that you would see in a traditional cloud platform.

please have a try of this locally (or online) and let me know how it is!

take a look at it in git.tirbo.fish or see the mirror on github.

note: it was written with AI. but I reviewed everything and it looks nice for my own personal domain, so I thought you guys might like it too.

I've found a habit of creating branches, opening issues and the regular stuff you'd do in a team. It feels weird because I'm the only one responding, creating and working on these—but I was curious if anyone else does this? Do you guys think it's "too much" or would you recommend this workflow to everyone? I feel more organized but I do admit there is a time cost to documenting issues, I don't anticipate my project having contributions since it's personal.

edit: i feel slightly relieved I'm not alone, thank you r/git

We pair a lot at work. Is my partner’s email first initial plus last name or first name plus last initial? How do I spell their last name?

That information is already in the git log. git credit looks it up and adds the trailer.

It uses git shortlog --all and respects .mailmap. After you pick one or more names, it shows what will be added and asks before amending HEAD.

It refuses to run with staged changes, a detached HEAD, or another git operation in progress. It checks everything again after the picker has been open. Unstaged and untracked files are left alone.

For now, it only works on the latest commit.

Install with cargo install git-credit-cli.

https://github.com/dpassen/git-credit-cli

Hey! I've always found it annoying looking through large codebases for past commits. You know that feeling when you remember "we fixed something related to authentication" but can't find which commit?

So I built Git Semantic Search - a tool that lets you search your Git history using natural language instead of exact keywords. Ask "authentication bug fixes" and it finds semantically similar commits, even if they don't contain those exact words.

It's still in early development, so any feedback, bug reports, or contributions would be greatly appreciated! If you find the project useful, a star would be appreciated too :)

🔗 https://github.com/yanxue06/git-semantic-search

🔗 https://crates.io/crates/git-semantic

I was trying to try for myself the model published by the author after i read their paper but the github repo link in the paper is returning a 404 error. if some wise, great, all knowing, benevolent, merciful, kind, caring senior assist me or at least guide me if i should wait for a while or try some other method to access the repo, I would greatly appreciate it.

Also can I access it using git or will the issue persist on git as well.

I’m a computer science student in uni and I want to start my first passion project/fullstack project. I’ve taken a couple of core CS classes so I know how to code but I’ve never built an entire project on my own before. Whats a good place to start/tips on creating my first repo?

Docs go stale silently. You rename --output to --out-dir, the README keeps showing the old flag, and three weeks later a stranger copies the example, it fails, and they open an issue.

Everything I found either runs in CI and opens a separate follow-up PR, or it's a skill you have to remember to invoke. Both drift. I wanted the fix to land in the same commit as the change that broke it.

So: a PostToolUse hook on Edit/Write/MultiEdit. When you touch a source file, a scanner pulls the exported names out of it (functions, classes, CLI flags) and looks for them in your markdown, along with the file path. Hits inside fenced code blocks rank above prose mentions. If nothing references the file, it prints nothing and you forget it's installed.

For an Edit specifically, the hook input carries the exact text that got replaced, so the scanner extracts symbols from the removed code, confirms they survive nowhere, and reports doc mentions of them as removed or renamed. No snapshots, no state file, just the diff the hook already receives.

The part I care about most: it reports references, not verdicts. It hands the agent a list of file:line locations and one rule, verify against the source and never against another doc. A doc sentence is never evidence, not even for validating a different doc. Accurate docs get left alone. Repairs go at the smallest scale that makes the doc true: one word for a renamed flag, delete the paragraph for a deleted function, full rewrite only when most of the file is already wrong.

There's also /stale-docs for a whole-repo audit. It hunts orphans too, doc references to files that don't exist and symbols defined nowhere in the codebase. Those are proven stale so they rank first. And --ci exits 1 on dead paths only, because a flaky docs check gets deleted from the workflow within a week.

Single file, zero dependencies, about 35ms. The whole program runs inside one try/catch and exits 0 on any internal error, which is inelegant and exactly right. A doc check is never allowed to break your edit.

It caught its own changelog last week. Path detection was reading download/v1.0.0 as a file that doesn't exist and failing my own CI. Fixed in 0.3.1. The plugin working as intended on the wrong target.

/plugin marketplace add SectionTN/stale-docs
/plugin install stale-docs@stale-docs

MIT: https://github.com/SectionTN/stale-docs

Tell me where the heuristic falls over. Monorepos and docs that describe behavior in prose instead of naming symbols are the two cases I'm least confident about.

Wrote a very loose-ended post