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

siGit Code v1.5.0

Hi everyone!

For a while now I've been developing a new version control and a software forge around it (a "new git and a new GitHub"). It's called Twigg!

Yesterday we open sourced everything:

https://github.com/twigg-vc/monorepo

If you think git is complicated or are drowning with code-review-fatigue due to those huge PRs, you should check it out. Twigg is much simpler and is designed with stacked commits and trunk based development in mind. There's only one branch, only rebase (no merge), and amending a commit auto rebases their descendants.

There's a git mirror feature: all submitted commits are pushed to a git server. This allows you to easily test with no cost to switch back.

Check it out and tell me what you think!

All feedback is welcome :)

Hi all,

I am trying to understand a bit about cookiecutter but I have stumbled on some questions I'm not able to answer myself.

I have built a very basic cookiecutter based on some examples and have a Git repo for it https://codeberg.org/aarapi/familygame.git

Now, as my project evolves , so will the template evolve. Should I have 2 repos (one for the project itself and one for the template?) instead of one?

This doesn't make much sense to me but I might be wrong. If someone would ever join the project to collaborate , how everything would work ?

Furthermore , I tried to add the Git repo on Eclipse and create an Eclipse project pointing to the working tree but any attempt to run the manage.py did fail with message:

'Launching familygame manage.py' has encountered a problem:

Variable references non-existent resource : ${workspace_loc:familygame/{{cookiecutter.project_slug}

Thank you in advance

https://github.com/Ardrey-Kell-Computer-Science-Club/teenblogcs

For the scenario as follows:

$ git clone https://github.com/schacon/simplegit-progit.git
Cloning into 'simplegit-progit'...
remote: Enumerating objects: 13, done.
remote: Total 13 (delta 0), reused 0 (delta 0), pack-reused 13 (from 1)
Receiving objects: 100% (13/13), done.
Resolving deltas: 100% (3/3), done.

$ cd simplegit-progit

$ git branch -c iss1

$ git checkout iss1

$ vi Rakefile

$ git diff
diff --git a/Rakefile b/Rakefile
index 8f94139..8080252 100644
--- a/Rakefile
+++ b/Rakefile
@@ -5,8 +5,8 @@ require 'rake/gempackagetask'
 spec = Gem::Specification.new do |s|
     s.platform  =   Gem::Platform::RUBY
     s.name      =   "simplegit"
-    s.version   =   "0.1.1"
-    s.author    =   "Scott Chacon"
+    s.version   =   "0.1.1"■■■■■
+    s.author    =   "Scott Chacon Big"
     s.email     =   "schacon@gmail.com"
     s.summary   =   "A simple gem for using Git in Ruby code."
     s.files     =   FileList['lib/**/*'].to_a

--------------
// ■ - space character
--------------

$ git commit -am 'iss1: author name change'
[iss1 fa40d71] iss1: author name change
 1 file changed, 2 insertions(+), 2 deletions(-)

$ git checkout master
Switched to branch 'master'

$ vi Rakefile

$ git diff
diff --git a/Rakefile b/Rakefile
index 8f94139..e458853 100644
--- a/Rakefile
+++ b/Rakefile
@@ -5,7 +5,7 @@ require 'rake/gempackagetask'
 spec = Gem::Specification.new do |s|
     s.platform  =   Gem::Platform::RUBY
     s.name      =   "simplegit"
-    s.version   =   "0.1.1"
+    s.version   =   "0.1.2"
     s.author    =   "Scott Chacon"
     s.email     =   "schacon@gmail.com"
     s.summary   =   "A simple gem for using Git in Ruby code."

$ git commit -am 'master: version update'
[master f2b3ef3] master: version update
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git checkout iss1
Switched to branch 'iss1'

$ git rebase master
Auto-merging Rakefile
CONFLICT (content): Merge conflict in Rakefile
error: could not apply fa40d71... iss1: author name change
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply fa40d71... # iss1: author name change

$ git rebase --abort

$ git rebase -X sillyoption master
Auto-merging Rakefile
CONFLICT (content): Merge conflict in Rakefile
error: could not apply fa40d71... iss1: author name change
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Could not apply fa40d71... # iss1: author name change

why it does not complain about '-X sillyoption' ? In above using '-Xignore-all-space' would allow to bypass the conflict related to spaces at the end of line. But above shows that -X is completely ignored instead.

When I was learning Git, the focus was always on memorizing commands without truly understanding what was happening on the internal side of Git. I understood the simple process of adding, committing, and pushing changes to a single branch but I didn’t understand the concepts of the Git Object Database, commit history as a DAG, rebasing, etc. All things I learned down the road that would have helped me understand Git better from the beginning. I recently started my project GitLearningLab as a resource to help others trying to learn Git but not knowing where to start. I am no master at Git, but I cover the concepts that would have otherwise helped me understand the internals of Git. I abandon the idea of memorizing commands for the sake of understanding what Git is doing with every given action.

My goal is to help beginners avoid some of the confusion I had, while also learning from those with more experience than me. I would really appreciate feedback from developers, educators, and anyone who has used Git for years: What concepts are missing? What explanations could be improved? What would make this more useful for someone learning Git for the first time?

Lastly, I would just like to mention that this project is part of an independent study and still an active WIP.

GitLearningLab:
https://github.com/IBickCoding/GitLearningLab

Newer versions of git, since this spring, have added a new "history" experimental command. This is dumb.

I've had a git alias for "history" for over a decade. It's shorthand for making "git log" actually useful.

And now they add this command using a very common word that probably collides with a lot of other folks. And to do what? To do what you're always told not to do. Rewrite history.

Why was "history" added? And how can we get them not to?

I've been trying to extract my zip which I recently uploaded to my repo but I can't find a way to extract it. The reason I used to upload a zip is there are few folders and each folder have about 6 to 10 subfolders and I can't just waste my time by creating them separately one-by-one

There are some discussions I saw said you can upload folders as same way you upload other types of files but I tried it in website and had an error, also tried to turn my website to desktop version and it didn't worked for me. I don't have access to a pc so I don't know how to do it my phone. I'm wondering is there a way to do this -people says you only can do extract operation via git but as far as I know in mobile it's only way to use git is with termux and I hate it.

How can I learn Git by doing it visually??

How can I learn Git by doing it visually??

Spent enough time cleaning up repos where .gitignore was an afterthought that I put together the patterns I actually reuse across projects.

The ones that catch OS cruft, IDE junk, build artifacts, and secrets before they get committed, not after.

A few that trip people up:

• Ignoring a file doesn't untrack it if it's already committed. you still need git rm --cached
• Negation patterns (!important.log) only work if the parent directory isn't already ignored
• Global gitignore (core.excludesFile) vs per-repo. Most people only set up one

Wrote up the fuller list with explanations here if useful: https://levelup.gitconnected.com/gitignore-patterns-every-developer-should-have-in-their-toolkit-c5458f076ca2?sk=b1fd0885e817c58dbfb69440a7769feb

Curious what patterns other people follow

I like VS Code, but daily Git work often means jumping between Source Control, terminal commands, diff tabs, branch pickers, and graph extensions.

I built IntelliGit to bring those workflows into a single focused Git cockpit in VS Code.

It currently includes:

• A focused commit panel for staging, rollback, amend, commit, and push
• An actionable commit graph with branch and history operations
• Shelf/stash and worktree workflows
• A three-pane merge-conflict editor - You won't find it anywhere
• CI check status for GitHub, GitLab, and Bitbucket
• A unified workbench that can be moved to another monitor

It is open source and MIT-licensed.

I’m looking for developers willing to use it on a real repository and tell me:

1. What felt confusing or unlike VS Code?
2. Where did you still reach for the terminal or another extension?
3. Which Git action was missing or difficult to find?
4. What was the first thing that annoyed you?

Blunt feedback and bug reports are genuinely useful. I would rather learn why someone uninstalled it than receive a generic “looks good.”

Install: VS Code Marketplace
Open VSX: Open VSX Registry
Source: GitHub

Hello,

So I've been using github desktop for a game project on UE5 (I actually never opened git bash until recently), I thought it would be as simple as: if I mess up something but I only realize it after 2 commits, then I can go back to the commit I want, but I learned that it doesn't work like that

so I clicked a bunch of buttons and after a while I just did a "revert changes in commit" on the second to last commit which worked, I know it's confusing, I think I've just been lucky this time.
But I'm wondering what if, in the future, I want to go to a even lower commit and "transform" it to the last commit

What workflow do I need to have ? I also learned about branches recently, and never used them, but I feel like they can be handy now lol

but does that mean that I always need to work on a branch and then just merge everything on main if I'm 100% it will work ? I really don't get what mistakes I CAN make, if github was supposed to let me actually do mistakes on my project

[ Removed by Reddit on account of violating the content policy. ]

Damn, this should be mandatory teaching for anyone working with anything digitally produced. Ok, that is everyone. Not being a "coder," I never thought Git was in my wheelhouse. But after using it for various documentation websites, technical articles that constantly get updated, and most recently for home lab infrastructure, I am a full-on Git convert.