Great tip, I have git add -p aliased to "gap" because I use it so often
Using Git add -p for fun (and profit)
61–70 of 80 posts
Re: Using Git add -p for fun (and profit)
#62Earlier quoted context omitted.
Dark mode looks fine to me: light gray on black. Light mode is terrible: dark gray on black.
You get light grey? The headings are #101828 and body text #364153 on #0a0a0a for me.
Light mode text: oklch(37.3% .034 259.733)
Dark mode text: oklch(87.2% .01 258.338)
Background in both modes: oklch(14.5% 0 0)
See here: https://jsfiddle.net/kmtwf4g3/
I think the fuckup of the website author is that the background is black instead of white in light mode. Otherwise the text colors would be fine as they are. Probably vibe coded and never tested in light mode.
Re: Using Git add -p for fun (and profit)
#63I almost exclusively use add -p. It's another moment to review my changes and it saves me from having to type out the names of the files I've changed. I don't know if I've ever committed a file unintentionally since adopting it. 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)
> I don't know if I've ever committed a file unintentionally since adopting it. I’ve had the opposite problem: forgetting to add new files. > 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) No need for the rebase to be interactive: $ git commit --fixup= $ git rebase --autosquash
> I’ve had the opposite problem: forgetting to add new files.
Any good solutions for this around?
For now I've adopted running `git status` after `git add -p` to make sure there's no untracked files, but it feels a bit clunky
Re: Using Git add -p for fun (and profit)
#64What'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…
> What's wrong with a big end of day commit?
It's useless for all but the code preservation part, it doesn't tell you anything.
> 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.
I would be very angry if someone deletes my work, why would I accept that? When my colleague throws my work into the bin, I will complain to my superior, they pay me for it after all.
> Maybe consider putting your energy into a good documentation inside the repository. I would love to have more projects with documentations which cover the timeline and ideas during development
That's what commit messages are? They provide the feature that you can click on any line in your codebase and get an explanation, why that line is there, what it is supposed to do, and how it came to be. That's very valuable and in my opinion, much more useful than a static standalone documentation.
First you think of commits as backups, then you think of them as a code distribution. Later you see them as a way to record time. What has been a useful insight to me was, what time is a prerequisite to: causality. Now I see that a VCS is less about recording actual history, but about recording evolution dependency, causality and intent. Also I perceive my work less to be about producing a final state of a codebase, but about producing part of the history of a codebase. My work output is not a single distribution of code, but documented, explainable and attributed diffs, i.e. commits.
Re: Using Git add -p for fun (and profit)
#65What'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…
> Maybe consider putting your energy into a good documentation inside the repository. 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 documentati…
A surprisingly large amount of devs, do the work to record data into a VCS (probably because they are told to by colleagues or superiors), but never seem to use them. Then they tell you that generating proper commits isn't all that important. Well, that's because they never actually use the VCS. By my book, only generating commits isn't really using a VCS, that is the information generation part, you also need to do queries on the collected data, otherwise yes it would be quite useless.
Re: Using Git add -p for fun (and profit)
#66Earlier quoted context omitted.
> I don't know if I've ever committed a file unintentionally since adopting it. I’ve had the opposite problem: forgetting to add new files. > 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) No need for the rebase to be interactive: $ git commit --fixup= $ git rebase --autosquash
> I’ve had the opposite problem: forgetting to add new files. Any good solutions for this around? For now I've adopted running `git status` after `git add -p` to make sure there's no untracked files, but it feels a bit clunky
You can run the tests on the actual produced commit, if you missed some files there would be a compilation error.
Re: Using Git add -p for fun (and profit)
#67Earlier quoted context omitted.
> I don't know if I've ever committed a file unintentionally since adopting it. I’ve had the opposite problem: forgetting to add new files. > 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) No need for the rebase to be interactive: $ git commit --fixup= $ git rebase --autosquash
> I’ve had the opposite problem: forgetting to add new files. Any good solutions for this around? For now I've adopted running `git status` after `git add -p` to make sure there's no untracked files, but it feels a bit clunky
I occasionally forget to add a new file but don't mind it much. I consider it a significantly smaller problem than committing a file that shouldn't be. CI is gonna run and my tests are surely gonna fail if I didn't commit some file. So I'll see that and commit --amend or fixup to add the new file.
unless the file I forgot to commit is the tests, which hopefully I'll catch by the time of the PR
Re: Using Git add -p for fun (and profit)
#68A disadvantage of git add -p is that it allows you to create a commit that never existed on the development system, and, hence, cannot have been tested. How do people handle that? One way would be to follow it up with git stash , running tests, and, if necessary, git amend , but that can get cumbersome soon.
>A disadvantage of git add -p is that it allows you to create a commit that never existed on the development system, and, hence, cannot have been tested.
The things you commit can always be different from what you test. In fact, if you know what you are doing, it is a feature to be able to create commits like this without testing. I certainly don't need to test my "Fixed typo in comments" commits...
>How do people handle that? One way would be to follow it up with git stash, running tests, and, if necessary, git amend, but that can get cumbersome soon.
Well, your CI system should be testing for you. But if you must test it locally, `git rebase` can either pause between steps or execute commands between steps. Finish making commits. If you made, say, 3 commits, then do `git rebase -i HEAD~3` and do break/exec as desired.
Re: Using Git add -p for fun (and profit)
#69What'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…
>What's wrong with a big end of day commit?
Hoo boy I guess you never tried to use `git blame` on years-old shit huh? Don't push a commit for every line, but for logical units like one particular feature or issue.
>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.
This doesn't just accidentally happen. There are tools to migrate repositories and to flush ancient commits in huge repositories. If you curate your commit history, this is probably never necessary, or may only become necessary after decades.
>Maybe consider putting your energy into a good documentation inside the repository.
Commit messages are documentation for code, basically. `git blame` associates the messages with individual lines and lets you step through all the revisions.
>I would love to have more projects with documentations which cover the timeline and ideas during development, instead of having to extract these information from metadata - which is what commit messages are, in the end.
The commit messages are for detailed information, not so much for architectural or API documentation. This doesn't mean you should get rid of commit metadata! Eventually, you will find a situation where you wonder what the hell you or someone else was doing, and the commit message will be a critical piece of the puzzle. You can also leave JIRA links or whatever in the message, although that adds a dependency on JIRA for more details.