git

Bilingual

Git without a forge
2 months ago
- Simon Tatham prefers plain Git repositories on his personal website over git forges like GitHub or GitLab.
- To send patches, he prefers: (1) providing a URL to a clone of his repo with your changes, (2) sending a git bundle file, (3) using git format-patch, (4) sending a git diff, and he strongly dislikes git send-email.
- He avoids forges due to trust concerns (preferring a friend-run server), the effort of running forge software, the requirement for users to create accounts, and the desire to avoid lock-in and monoculture, especially with GitHub.
- He acknowledges that forges offer public visibility of contributions but believes the disadvantages outweigh the advantages for his projects.
If I Could Make My Own GitHub
2 months ago
- Current forges like GitHub, GitLab, and Gitea all follow the same pattern set by GitHub, with little connection to actual git usage; most workflows happen inside the forge rather than on the client.
- Git is designed for decentralized patch-based kernel development, but most users treat it as a centralized pull/push system, with forges handling identity, reviews, CI/CD, and releases.
- Pull request workflows have problems: commits often come in wrong order with fixes piling up; feedback should happen via pre-commit hooks run on the forge before pushing.
- PR approval is too binary; a 'weak approval' or 'deal with it later' option should exist, similar to Gerrit's model.
- PRs are too inflexible; not all changes need four eyes, especially with LLM assistance; maintainers and low-risk changes should bypass strict review.
- Stacked PRs should be a first-class feature, not an add-on, because they are easier to review and understand.
- A forge should not try to do everything; it should focus on core features like issue tracking and version control, not include kanban boards or wikis that become maintenance burdens.
- Hosting units should be smaller and more modular; an organization should be able to run a forge on a few Raspberry Pis without complex deployment.
- Local repo copies should represent the entire repository state (issues, PRs) and allow actions like approving PRs from the local VCS.
- Since online access is usually available, cloning should be shallow by default; deep history should be fetched on demand to reduce storage and bandwidth.
- Actions should be signed, SHA-pinned, and usable offline; users should be able to bundle them into the repo and update via Dependabot-like PRs.
- The ideal forge would use a modern VCS like JJ, integrate shallow clones and object storage, and be resilient to constant LLM bot traffic.
- Despite other tools existing piecemeal, no one has built a complete replacement for the deteriorating monolithic forge model; the author hopes to build one if they become wealthy.
Stop Using (only) GitHub Releases
2 months ago
- The author accidentally upgraded Rust dependencies and faced difficulties because projects lacked CHANGELOG.md files, relying solely on GitHub releases.
- GitHub releases have downsides: pagination makes cross-referencing hard, they are not part of the repository, and they are at risk of being lost if GitHub declines.
- A CHANGELOG.md file in the repository migrates with the code and should be the primary source of release notes.
- The principle extends beyond changelogs: commit messages should explain why changes were made, documentation should be in markdown files, and any project-related data expressible as files should be stored as files in the repository.
Git cheats
2 months ago
- Git has a great data model but an unfriendly user interface.
- If you lose a commit, run `git reflog` to find recent commits.
- After a rebase, use `git push --force-with-lease` instead of regular `git push` to avoid rejection.
- If you accidentally merge after `git pull`, use `git reset --hard HEAD~` to undo the merge commit.
- A detached HEAD means you're not on any branch; create a new branch with `git checkout --branch <name>` to save work.
- To overwrite untracked files, commit changes first or use `git submodule deinit` or delete files carefully.
- In rust-lang/rust, modify Cargo.lock by updating submodules with `./x.py --help`.
- Amend last commit with `git commit --amend`; fix earlier commits with `git commit --fixup` and `git rebase --autosquash`.
- Remove a merge commit by rebasing onto the default branch with `git rebase -i origin/HEAD`.
- Error messages in Git are often unhelpful; better messages would guide users to correct solutions.
pre-commit hooks are fundamentally broken
2 months ago
- Pre-commit hooks run on the working tree, not the index, causing issues with staged changes.
- They interfere with rebasing, especially interactive rebases, and can fail when files are missing.
- They prevent saving work-in-progress commits and are not suitable for incomplete code.
- Pre-commit hooks are often slow, unreliable, and implemented in broken ways.
- The author recommends using pre-push hooks instead, which avoid most of these issues.
- The only acceptable use for pre-commit hooks is to prevent committing credentials.
- Tips for pre-push hooks: run on the index, be fast and quiet, and do not auto-install.
I taught a bucket to speak git | Tigris Object Storage
2 months ago
- The author taught a bucket to function like a filesystem using billy, an abstraction originally for go-git, enabling git operations on object storage.
- Git repositories consist of objects, trees, commits, and refs; objects are content-addressed and append-only, fitting Tigris object storage well.
- Storing git repos on single machines creates stateful services and potential failures; GitHub's scale forces reliance on mounted filesystems.
- Alternatives like shelling out to git binary, libgit2, or libgit2 have limitations (e.g., process death, GPL issues, or local filesystem assumptions).
- go-git, a pure Go library, doesn't depend on local filesystems, allowing objgit to work with Tigris via billy's interface.
- Objgit successfully supports push/pull over HTTP, git://, and SSH, with repositories created on first push and metrics for optimization.
- Key challenges included: lack of atomic rename in object storage (solved by Tigris's RenameObject), pack file buffering, and excessive stat() calls during pushes.
- Performance issues were addressed by caching immutable pack files locally and fixing a recursive listing cache to reduce ListObjectsV2 calls.
- Post-receive hooks run in sandboxed environments (kefka) with limited access, enabling CI-like actions without network or host filesystem.
- Future plans include CI integration, a web UI, and performance improvements, emphasizing a stateless git server on object storage.
Staging patches with Git add -p
2 months ago
- `git add -p` allows interactive staging of file changes, enabling review and error detection during the commit process.
- It can split changes into hunks for selective staging, helping organize related modifications into separate commits.
- The feature provides various options like 'y' (stage), 'n' (skip), 's' (split), and 'q' (quit) for fine-grained control.
- It is not suitable for new files (no diff available) but is useful in most other scenarios, including partial file commits.
- Using `git add -p` improves commit organization and reduces errors by enabling code review at staging time.
git's –end-of-options Flag
2 months ago
- Git's --end-of-options flag, introduced in 2019, marks the end of option parsing for revisions, distinct from -- which separates revisions from pathspecs.
- Argument injection (CWE-88) occurs when untrusted strings starting with a dash are passed as arguments to git, hg, or ssh, even without a shell involved.
- Only one of 17 package managers that fork git uses --end-of-options; others rely on -- or dash checks, often added as vulnerability fixes.
- Minimum git version requirements for --end-of-options vary by subcommand, with support ranging from 2.24.0 to 2.43.1, making adoption challenging for older distributions.
- Git libraries like libgit2 avoid argument injection by not using an argv interface, but must track all checkout-safety patches from upstream git.
Git rebase -I is not that scary
2 months ago
- The author expresses surprise at the common fear of git rebase -i among developers, even those more experienced, and aims to demystify it.
- Running git rebase -i HEAD~4 opens a text file with a list of recent commits and commands (pick, reword, squash, fixup, drop), which is a plan for changes, not an immediate action; users can abort with git rebase --abort.
- Interactive rebasing involves editing instructions per commit (e.g., rewording messages or dropping commits), creating new commits while leaving old ones intact in git's object database until garbage collection.
- Safety measures include: git rebase --abort to bail out, the reflog to restore previous states (e.g., git reset --hard HEAD@{4}), and creating a backup branch (git branch backup-before-rebase).
- Conflicts may arise during rebasing, but they are resolved one commit at a time (similar to merge conflicts) using git add and git rebase --continue, making them easier than branch merges.
- The author advises using rebase freely on personal feature branches and pushing with git push --force-with-lease (preferable over --force for safety), while emphasizing understanding and care.
- The key takeaway is that developers should learn and use interactive rebasing to maintain clean branch histories, with the post encouraging beginners to try it and overcome fear.
The Git history command deserves more attention
2 months ago
- Git history is a new experimental feature in Git that introduces three subcommands: fixup, reword, and split.
- fixup allows staging changes and folding them into an old commit, then automatically rebasing all branches that contain that commit.
- reword updates the commit message of an old commit and automatically rebases everything on top without touching the working tree.
- split divides a single commit into two by interactively selecting hunks, rebuilding the stack on top.
- All three commands are atomic and avoid leaving the tree in a half-broken state by refusing operations that could cause conflicts.
- Unlike jj, git history does not handle conflicts as first-class yet, but the documentation suggests this may change in the future.
- git history offers many benefits of jj without requiring a full workflow switch, and it's part of the core Git distribution.
Why don't people use Git properly?
3 months ago
- The author introduces Arca, an educational project with a landing page, offering early access soon and free slots for donors.
- Git is a crucial version control system widely used in software development, but many people struggle with it, leading to issues like merge conflicts, poor commits, and misuse of repositories.
- The problem stems from inadequate education and experience with git, especially among those who are not in core software roles and lack institutional support or motivation to learn.
- A significant barrier is git's reliance on command-line interfaces, which many developers, especially those on Windows or using IDEs without CLI familiarity, find non-intuitive and difficult to master.
- People often don't understand the problems git solves, such as fast rollbacks, deployment automation, and risk-taking in development, because they lack hands-on experience with projects that require these features.
- The author compares git to Roman armor, explaining that the safety it provides allows developers to take more risks and be more ambitious, but without experiencing this security, users may develop defensive habits and avoid new tools.
- To improve git usage, the author suggests integrating version control early in education and promoting DevOps rotations in companies, but acknowledges the challenges in scaling these solutions.
Magit 4.6 Released
3 months ago
- Magit version 4.6 released with 313 commits since the last release.
- Magit is a text-based Git user interface streamlining workflows with mnemonic key sequences.
- Improvements focus on blob-visiting buffers, enhancing performance and user experience.
- Volatile blob buffers are cached for reuse, supporting features like syntax-highlighting.
- Blobs can be visited using only a blob object id, not requiring a revision and path.
- Added syntax highlighting for diffs, but it's disabled by default due to synchronous processing delays.
- Future support for asynchronous diff syntax highlighting planned.
- New Git variables introduced for calling Elisp hooks from Git hooks, requiring Git v2.54.0 or greater.
- Commands added for compiling lists of modified definitions in diffs and inserting them into commit messages.
- Completion of symbols in commit messages now includes modified definitions and symbols from changed lines.

Git without a forge

If I Could Make My Own GitHub

Stop Using (only) GitHub Releases

Git cheats

pre-commit hooks are fundamentally broken

I taught a bucket to speak git | Tigris Object Storage

Staging patches with Git add -p

git's –end-of-options Flag

Git rebase -I is not that scary

The Git history command deserves more attention

Why don't people use Git properly?

Magit 4.6 Released