Tag: Git

mise-en-place documentation

I've been using GitLab for years for all my private projects. Some thoughts on why it stuck.

I list my most used Jujutsu commands and how I use them.

Developer setups, editors, and dotfiles. Click to read .dotfiles, by Adib Hanna, a Substack publication with thousands of subscribers.

This site uses Typst for its content, and so do my videos, and everything else

As all developers, I’ve been using git since the dawn of time, since its commands were an inscrutable jumble of ill-fitting incantations, and it has remained this way until today.
Needless to say, I j

Get to know the latest open source toolkit from GitHub that allows you to use Spec-Driven Development in any AI coding agent.

Making dwm as beautiful as possible! . Contribute to siduck/chadwm development by creating an account on GitHub.

DASH - a rich terminal UI for GitHub that doesn't break your flow

A Jujutsu tutorial that requires no previous experience with Git or other version control systems.

GitButler software development platform

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can't search for how to get yourself out

An experience report from using Jujutsu at work.

GitHub issues is almost the best notebook in the world. Free and unlimited, for both public and private notes. Comprehensive Markdown support, including syntax highlighting for almost any language. Plus …

Make your diffs human readable for improved code quality and faster defect detection. :tada: - so-fancy/diff-so-fancy

jjui is a TUI designed for interacting with the Jujutsu version control system. - idursun/jjui

Fork - a fast and friendly git client for Mac and Windows

In this post, I demonstrate the optimal workflow for creating new Debian packages in 2025, preserving the upstream Git history. The motivation for this is to lower the barrier for sharing improvements to and from upstream, and to improve software provenance and supply-chain security by making it easy to inspect every change at any level using standard Git tooling.\nKey elements of this workflow include:\nUsing a Git fork/clone of the upstream repository as the starting point for creating Debian packaging repositories. Consistent use of the same git-buildpackage commands, with all package-specific options in gbp.conf. DEP-14 tag and branch names for an optimal Git packaging repository structure. Pristine-tar and upstream signatures for supply-chain security. Use of Files-Excluded in the debian/copyright file to filter out unwanted files in Debian. Patch queues to easily rebase and cherry-pick changes across Debian and upstream branches. Efficient use of Salsa, Debian’s GitLab instance, for both automated feedback from CI systems and human feedback from peer reviews. To make the instructions so concrete that anyone can repeat all the steps themselves on a real package, I demonstrate the steps by packaging the command-line tool Entr. It is written in C, has very few dependencies, and its final Debian source package structure is simple, yet exemplifies all the important parts that go into a complete Debian package:\n

How Jujutsu's flexibility and safety changed my approach to version control.

An opinionated list of CLI/TUI applications for developer productivity.

A guy decides to show off his Neovim setup.

Découvrons ensemble comment utiliser le GPG pour sécuriser ses échanges (fichiers, mail, commits) et comment stocker ses clés sur une Yubikey pour plus de sécurité !