41–50 of 80 posts
I like it especially in concert with git commit --amend, which lets me tack my newest changes onto the previous commit. (Though an interactive rebase with fixup is even better)
What's wrong with a big end of day commit? Sure, a well crafted git history can be very valuable. But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost. Maybe consider putting your energy into a good documentation inside the repository. I would love to have more pro…
Commit messages are documentation.
If you have a good commit history you don't need write tons of documents explaining each decision. The history will contain everything that you need, including: when and who changed the code, what was the code change and why the code exists. You have a good interface for retrieving that documentation (git log, perhaps with -S, -G, --grep, -L and some pathspecs) without needing to maintain extra infrastructure for that and without being cluttered over time (it will be mostly hidden unless you actively search that). You also don't need to remember to update the documents, you are forced to do that after each commit.
And that's not a hack, Git was made for that.
There are many other plugins for vim and emacs (e.g. magit) that enhance one’s git workflow.
the / (search) command to search unstaged hunks for a specific keyword rather than having to jump through all the individual changes you've made when there's lots.
and the e (edit) command to manually split out two changes that end up in one hunk that I'd rather have in individual commits.
Earlier quoted context omitted.
It hasn't been an issue in my experience at $DAY_JOB, but for us all commits must pass CI and not just the tip of whatever branch was just pushed. So branches with partial commits that fail CI cannot be merged. So if you commit an incorrect partial commit, you either squash it into a commit that does pass CI (usually the next one forward) or you rebase and edit the failed commit and fix it and force push your branch…
If you push a branch with many commits, does it run CI on each commit? In sequence or with some parallelism?
This is the second link from the HN start page that doesn't load due to La Liga censoring in Spain.
https://archive.today/Ig42c (has issues with Cloudflare DNS)
https://web.archive.org/web/20251214151943/https://techne98....
What's wrong with a big end of day commit? Sure, a well crafted git history can be very valuable. But then comes somebody and decides to just flush your well curated history down the toilet (=delete it and start somewhere else from scratch) and then all the valuable metadata stored in the history is lost. Maybe consider putting your energy into a good documentation inside the repository. I would love to have more pro…
For me the point of splitting commit is not for documentation (though it can be an added benefit). It is so that you can easily rollback a feature, or cherry pick, it also makes the use of blame and bisect more natural. Anyways, that's git, it gives you a lot of options, do what you want with them. If a big end-of-day commit is fine for you, great, but some people prefer to work differently. But that's not actually t…
This is the second link from the HN start page that doesn't load due to La Liga censoring in Spain.
Here's a couple archive links that may help you get around that: https://archive.today/Ig42c (has issues with Cloudflare DNS) https://web.archive.org/web/20251214151943/https://techne98....