19 Matching Annotations
- Jan 2024
-
git-cliff.org git-cliff.org
-
Getting Started git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers. The changelog template can be customized with a configuration file to match the desired format.
with emacs
Tags
Annotators
URL
-
- Sep 2023
-
-
What can we do to undo this commit?
-
- Aug 2022
-
gitlab.com gitlab.com
-
Each commit should meet the following criteria: Have a well-written commit message. Has all tests passing when used on its own (e.g. when using git checkout SHA). Can be reverted on its own without also requiring the revert of commit that came before it. Is small enough that it can be reviewed in isolation in under 30 minutes or so.
-
- Feb 2021
-
github.com github.com
-
@kirs can we leave the typecast API out for now? This will conflict with the work @sgrif want to do and it would maybe make harder to integrate.
-
- Nov 2020
-
github.com github.com
-
Bonus SSR bugs I bumped into and fixed while addressing this:
-
- Oct 2020
-
github.com github.com
-
github.com github.com
- Aug 2020
-
github.com github.com
-
The collection of changes to fix the issues we want to address would be probably of the same size, but it would make easier to review and merge if we could break this PR in many steps. I find it really hard to believe we need to change 170 lines in a single commit to be able to fix this issue. We probably could break the first commit in many commits, test the class better and that would give more confidence over what is being changed. Right now I see a huge diff, with a few assertions changes and no real reason why all those lines had to change.
-
- May 2020
-
github.com github.com
-
# Two commits are considered the same if they have the same tree and # the same commit and author metadata. This is how we re-identify # commits after their hash IDs have been rewritten.
-
-
gitlab.com gitlab.com
-
Having to rebase and cleanup the commits while actively working on something is time and attention consuming.
I'm not sure how I feel about that. Usually I'd say it's worth it to do it periodically, even while you're working on it. Just not obsessive compulsively to the point that it is distracting from actual work.
-
which might or might not be useful depending on what is the content of the commit.
-
Just to make this clear, I'm on the side that adding strict rules doesn't necessarily improve a situation. Especially with something that is subjective like a commit message.
-
These two are in my opinion the most problematic — the basically go against each other. Typically, I try to work in increments over a feature and commit when I reach whatever techinical milestone I want to "checkpoint" at. It can also be out of the need to expose some idea or architecture and push it.
-
Good commit hygiene in general is a tough thing to enforce. It requires manual labor and descipline, from both the author and the reviewer.
-
If we can encourage people to create clean commits as they go, the example as you showed above should be far less common, because cleaning up such history as an after-math is most of the time almost impossible.
Tags
- useful
- enforcement
- it depends
- iterative process
- distracting
- balance
- do it right/well the first time because it may be too hard to clean up/fix later if you don't
- requires discipline
- too many rules/policies not necessarily helpful/a good thing
- commits
- subjective
- good commits
- commits: when/how often to commit
- good commit messages
- requires great effort/time/resources
- good policy/practice/procedure
- time wasters
Annotators
URL
-
- Apr 2020
-
github.com github.com
-
Test on more recent rubies
-
-
mutabit.com mutabit.com
-
comoversionado semántico
Acá sería bueno reemplazar en enlace por la página en español:
-
-
hswolff.com hswolff.com
-
Each commit is composed so you can read them from start to finish and see what was done to get to the next iteration of the application.
-