A git bingo: did you hear all of these?

Git can be extended in many ways. The author of b4 created a cli tool to simplify the patches communicated by email for the linux kernel developers.

Notes stow metadata about anything tracked by git—any object: commits, blobs, and trees.

The git project itself offers an example of git notes in the wild. They link each commit to its discussion on their mailing list.

Other folks are using notes for things like:

• Tracking time spent per commit or branch
• Adding review and testing information to git log
• And even fully distributed code review

Review notes are used by Gerrit (Wikimedia) and many google projects. For example:

commit d1d17908d2a97f057887a4afbd99f6c40be56849
Author: User <user@example.com>
Date:   Sun Mar 27 18:10:51 2022 +0200

    Change the thing

Notes (review):
    Verified+1: SonarQube Bot
    Verified+2: jenkins-bot
    Code-Review+2: Reviewer Human <reviewerhuman@wikimedia.org>
    Submitted-by: jenkins-bot
    Submitted-at: Tue, 14 Jun 2022 21:59:58 +0000
    Reviewed-on: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/774005
    Project: mediawiki/core
    Branch: refs/heads/master

There is also an extension from Google to git notes dedicated to code review: https://github.com/google/git-appraise. Request review, comment and review and merge are included.

Its authors have declared it a “fully distributed code review”—independent of GitHub, GitLab, or any other code forge.

Git notes are however a pain to use. Mhmhmhm #idea #project on top of the git note commands?

For commits, you can make viewing and adding notes easier using fancy options in your gitconfig3. But for storing notes about blobs or trees? Forget it. You’d need to be comfortable rooting around in git’s plumbing first.

Much of the value of git repos ends up locked into forges, like GitHub. Git notes are a path toward an alternative and it could make it possible to distribute the history of an entire project.

Critics of Git, if someone had to improve from its weaknesses.

sha1 was a bad choice back then. The moral here is "treat your identifiers as opaque strings" along with "sometimes a sha1: prefix doesn't hurt anyone"

Email and names in every commits:

I guess when you read lkml, the notion of spam isn't too worrying, but putting names and emails into every commit means any time someone changes name or email, they might as well be a whole different person to the repo.
Sure enough, when you store names in the files, you have to rewrite history when someone changes email address, but in another world, you'd use a UUID and a file called .gitauthors that maps one to the other

There are two different mechanisms for almost every feature.

git forces you to make a choice. use merge and get a noisy, but representative history. use rebases and lose some of the work, but the log is a lot easier to navigate.
we could also have a version of git log that didn't make merges look like shit, but that's another problem altogether.

the unix philosophy is about building toolkits, not applications

in other words: have you ever accidentally committed inside a rebase? or accidentally committed a conflict? tough shit, fucko.
git commands are named after implementation, not use, and there's absolutely no excuse for it
flat files kind of suck if your state gets corrupted.

git is made from papercuts

there's bits where you can't check in an empty directory, or how you can set files to ignore but not files to include.

#project #idea make it better

We care about the number of concepts that changed in a particular PR.

The smaller the PR the more likely it will be to get merged quickly

Rules:

1. Don't waste your reviewer's time by showing them all your failed experiments in your Git history.
2. Maintain a Git history closest to the true essence of the work done, creating many small PRs that each make one releasable change to the codebase and keeping the number of commits as low as possible.

What I can improve is to remove (fixup or squash) all these tries/little fixes that I add in the commit history.

Use a web UI to ensure compatibility.
Operations are made through system calls of Node, Bun or deno or the git cli command as the FileSystem API is not widespread.

Git has become a complete tool. I missed a lot of it, but I am not sure I will need it as it is most of the time for big repositories.

git config --global --add --bool push.autoSetupRemote true

So the branch will be set if it is not the case 👍
It needs git version 2.37.0 or superior.

So it is possible to leverage the power of git :D

More git tips and tricks.
Aliases are underused

*de l'architecture

A CLI alternative to classic GUI interfaces

edit 2024: the project got more flexibility.

• smartlog list only your commits
• one PR one with stacked commits (https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/)

and more