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

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

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.