3 ms·

> To basically never just "git add ." whatever might just happen to be different in their work area > I will start to commit change sets as parts of the code s

> To basically never just "git add ." whatever might just happen to be different in their work area > I will start to commit change sets as parts of the code solidify without committing other less solid changes I feel like you are pushing your idiosyncratic way of working on others. It's great that you have a way that works for you, but it seems rather odd to me that you would ever be working on more than one thing in the same staging area. I always git add -a . because I'm working on one specific thing, and my tests just passed.

s1gsegv 2y ago
The thinking is that you might’ve instrumented other code or de optimized it in a way that you don’t want to commit while solving the problem.
thebruce87m 2y ago
You never fix an unrelated typo or add something useful to the README that you couldn’t find but needed?
- hyperman1 2y ago
  Since I started with lazygit, I do it a lot less. The tool makes it extremely easy to select what changed lines belong to which commit. And easy things are done more commonly than hard things.
- steveklabnik 2y ago
  jj makes this extremely easy by the way. One sample way to do it: 1. jj new (create new change) 2. <make typo fix> 3. jj edit @- (please go back to editing the previous change: @ is the working directory, - means previous. kinda like HEAD^ in git) You're done in a few seconds, and can get back to your regular work, while that change is split out into its own thing. If you're not as comfortable with the anonymous stuff, you could also `jj new -m 'typo fix'` to set a message then, but for small stuff like this, I don't personally bother until I am done with what I'm actually working on and am ready to submit that too. If you’re treating @ like the git index (sometimes called the “squash workflow”) then you’d just do the same thing you do in git: squash each part of @ into the proper commit. Of course, you could also just make it in the current change, and split it out later, but that's easier to forget imho.

s1gsegv 2y ago

The thinking is that you might’ve instrumented other code or de optimized it in a way that you don’t want to commit while solving the problem.

thebruce87m 2y ago

You never fix an unrelated typo or add something useful to the README that you couldn’t find but needed?

hyperman1 2y ago
Since I started with lazygit, I do it a lot less. The tool makes it extremely easy to select what changed lines belong to which commit. And easy things are done more commonly than hard things.
steveklabnik 2y ago
jj makes this extremely easy by the way. One sample way to do it: 1. jj new (create new change) 2. <make typo fix> 3. jj edit @- (please go back to editing the previous change: @ is the working directory, - means previous. kinda like HEAD^ in git) You're done in a few seconds, and can get back to your regular work, while that change is split out into its own thing. If you're not as comfortable with the anonymous stuff, you could also `jj new -m 'typo fix'` to set a message then, but for small stuff like this, I don't personally bother until I am done with what I'm actually working on and am ready to submit that too. If you’re treating @ like the git index (sometimes called the “squash workflow”) then you’d just do the same thing you do in git: squash each part of @ into the proper commit. Of course, you could also just make it in the current change, and split it out later, but that's easier to forget imho.