Bilingual

Magit 4.6 Released
22 days 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.
Why don't people use Git properly?
21 days 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.
The Git history command deserves more attention
12 days 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.
Git rebase -I is not that scary
11 days 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.
git's –end-of-options Flag
4 days 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.
Staging patches with Git add -p
7 hours 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

Magit 4.6 Released

Why don't people use Git properly?

The Git history command deserves more attention

Git rebase -I is not that scary

git's –end-of-options Flag

Staging patches with Git add -p