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

Some examples of why C is faster than Java, because C and algorithms

A random git commit joke on each refresh :D

And only the text version of it: http://whatthecommit.com/index.txt

About the workflow with Git and best practices 👍‍

I find it also useful to run eslint src/* ---fix

I hop cargo fmt in the future.

Mhmhmh ok ! I note the hyperfine command to benchmark the speed of cli commands :)

Si vous travaillez (et je vous le souhaite) dans un environnement qui n’a pas ces besoins, je vous invite à vous interroger sur vos propres pratiques.

Il est normal que quand on développe on soit attaché au produit de son travail, et vouloir faire les choses proprement est louable, mais j’ai l’impression qu’on a parfois tendance à porter une attention excessive aux commits et à l’historique git.

Cela ne veut pas dire systématiquement prendre le contre-pied du noyau Linux, mais qu’il faut savoir investir son énergie là où elle est le plus utile.

L'historique est vital pour GNU/Linux. Si des PRs durent des années, qu'ils faut adapter le code, l'abandonner ou le reprendre d'une autre personne, etc... effectivement avoir un historique et des commits normés et clairs sont primordiaux.

Programming languages are not really just lines of text. Diffs from two different changes to a source file are not necessarily composable, even if there are no overlapping changes. Program code has syntax, and this syntax is knowable, even in the case of the most dynamic of languages (such as those with configurable readers such as Common Lisp). A source file, if it isn't broken, represents a particular structured object, an abstract syntax tree.

We should be able to leverage this.