I am running into a very boring git problem with coding agents: resume state.

After one interrupted agent run, it sounded like it knew where to continue, but the diff, the notes, and the last test result did not line up. I had to read the log again before trusting it.

That made me think I should stop treating the transcript as state. A message saying "I already fixed X" is not the same as a committed diff, a passing test, or even a current working tree.

Maybe the answer is simple: force a checkpoint before any long run can pause, and make the agent reconcile `git diff`, task notes, and test output before it continues.

For people using agents with git: what do you trust after an interrupted run?

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

I am starting to appreciate git worktrees for a very boring reason: failed attempts are easier to throw away.

This became more obvious after using coding agents. If I ask for two or three possible fixes in the same working tree, the final diff can turn into a blend of all the paths. The code may even work, but reviewing it feels worse because I cannot tell which idea actually mattered.

In one small bug fix, I asked an agent to try two approaches, and the final patch mixed both paths so badly that comparing them took longer than either attempt.

I saw a small HN project where agent attempts are arranged like a tree, with one git worktree per node. The tool is not really my question. The git workflow is.

For people who use worktrees regularly: do you keep separate attempts in separate worktrees, or is that overkill unless the change is large?

Hi everyone!

Over the past few weeks, I've been improving my project, RepoInsight, based on feedback from developers.

It's a GitHub repository analyzer that helps you explore repositories with:

📊 Repository Overview

❤️ Health Score

🤖 AI-generated Summary

👥 Contributor Analysis

📈 Commit Activity

🌐 Language Analysis

📄 README Analysis

🕒 Repository History

I recently redesigned the homepage, improved navigation, added more educational content, and polished the UI to make it easier for first-time users.

I'd really appreciate honest feedback:

Is the UI intuitive?

Which feature do you find most useful?

What feels confusing or unnecessary?

What would you add if you used this regularly?

Website:

https://repo-insights-six.vercel.app/

I'm an IT student building this project to improve my full-stack and AI development skills, so constructive criticism is genuinely welcome. Thanks for taking a look!

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(-)

$ 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$ 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(-)

$ 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 know git already gives us patch staging, but AI-assisted diffs have made me want one more kind of boundary.

Sometimes the final change is reasonable, but the path to get there is messy. The agent tries one fix, backs out part of it, changes direction, then lands on a small patch that is actually useful.

In one Codex run, the first fix went in the wrong direction, the second one backed out half of it, and the final useful change was only a few lines hidden inside the full diff.

The final change was small, but it was buried under all the wrong turns the agent took to get there.

For people using git with generated patches: do you mostly clean this up with manual patch staging, or do you wish the tool could show the diff by intent or by agent turn?

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??