4 ms·
> I haven't seen a practical example of a use case that's improved by having separate add and commit. Well, I frequently see random things to fix while I'm wor
by erichocean 10y ago
> I haven't seen a practical example of a use case that's improved by having separate add and commit.
Well, I frequently see random things to fix while I'm working on a problem.
When I 'm ready to commit, I run `git status` and notice there's a file that's been modified that's unrelated to what I'm trying to commit.
A quick `git diff` later and I see what I did: fixed an unrelated issues. So I add that one file to the index, commit it with a relevant commit message, and then proceed to do a second commit—the one I had expected to do—also with a relevant commit message.
I do this 3-5 times a day, at least.
- hefty 10y ago>there's a file that's been modified that's unrelated to what I'm trying to commit What if those unrelated changes are in the same file as a bunch of related changes that you've already made? Do you undo all the changes you've made in that file apart from the random bug fix and then commit, or leave them intact resulting in that bug fix commit containing changes that are unrelated to the fix?
- nickhuh 10y agoIn that case you'd want to use "git add -p" which allows you to pick only parts of a file to stage for a commit. It can be crucial in crafting a really solid project / commit history. For even more complex cases you could use "git add -i"; however, that command can be tricky to work with and I find it's usually not to helpful to get that far into the weeds.
- erichocean 10y agoAtlassian has a nice UI for doing that visually, too. Super easy. Honestly, people for whom the command line UI is "too difficult" should just use a GUI client. That's the target audience for them.
- recursive 10y agoI do this kind of thing often too. To me this all seems like it could be handled at commit time. And more simply too.