5 ms·

I regularly hack on a slightly larger feature, fix, whatever. Once it's working, I incrementally stage lines for the separate commits that'll make up something

I regularly hack on a slightly larger feature, fix, whatever. Once it's working, I incrementally stage lines for the separate commits that'll make up something reviewable. Doing a line-by-line review of the change at the same time. Often I'll omit some too-verbose or too hacky debugging that I don't want to include. Once that's done I'll start a script that verifies that all the incremental commits individually pass tests (and maybe grab a coffee). While the tests run I'll do a separate pass over the commits. For me the staging is absolutely crucial, and I can't imagine wanting to go back.

magicalhippo 5y ago
I'm not saying staging should go away. I'm saying it should work in reverse. Instead of having all the changes in your working directory and commit some temporary state not reflected in the working directory, I'd like to move my changes into a temporary area and then pick the lines into my working directory and commit that. That way I can compile and run tools etc on the code that will be committed before committing. If I'm not ready to commit everything, I could then stop the "commit mode" and my uncommitted changes would be brought back into the working directory. At least that's what I dream of.
- stormbrew 5y ago
  Huh this is actually a kind of interesting idea. So basically if `git stash apply` had a --patch or --interactive mode? So the flow would be: <working on big change churn churn churn> > git stash > git stash apply -p <pick some things to have in working tree> > make test > git commit -a -m "First change!" > git stash apply -p <pick some more things> ...repeat... ? I could get behind that, and I personally like the index.
  - magicalhippo 5y ago
    I haven't thought about the specifics, but yeah that looks like a very nice variant. Since Git has stash, it feels like my idea is mostly a frontend thing that shouldn't require much backend changes, if at all.
- sagarm 5y ago
  Seems equivalent to a git add -p # Review and stage git commit # Create commit git stash # Save uncommitted changes run_tests.sh # double-check git stash pop # or drop I'll do something like occasionally, but mostly I just rely on the CI to double-check me.
  - gfxgirl 5y ago
    Yes, that is equivalent, except that you had to be aware of the staging area and its implications. CIs on large teams can't run fast enough to check every individual commit. They have to run them in bulk. So the CI will often not catch that of your 2 consecutive commits the first one breaks if the 2nd one fixes that break.
    - sagarm 5y ago
      I've also worked on large teams, and for us every published version of every change within our project is automatically tested. If your CI is too expensive to run on every commit it probably needs optimization -- something I've done myself a few times. Not investing time or resources into making your CI fast and reliable is a false economy IMO.
- zoomablemind 5y ago
  > ...I'd like to move my changes into a temporary area and then pick the lines into my working directory and commit that. One way to achieve this is by putting the changes into stash 'git stash push', then interactively grab the desired hunks from the stash into the work dir with 'git checkout --patch stash@{id}'. This will also add the accepted changes into the index, staging them for the commit. Kinda granular, but allows me to keep those nice verbose debugging parts yet out of commit.

magicalhippo 5y ago

I'm not saying staging should go away. I'm saying it should work in reverse. Instead of having all the changes in your working directory and commit some temporary state not reflected in the working directory, I'd like to move my changes into a temporary area and then pick the lines into my working directory and commit that. That way I can compile and run tools etc on the code that will be committed before committing. If I'm not ready to commit everything, I could then stop the "commit mode" and my uncommitted changes would be brought back into the working directory. At least that's what I dream of.

stormbrew 5y ago
Huh this is actually a kind of interesting idea. So basically if `git stash apply` had a --patch or --interactive mode? So the flow would be: <working on big change churn churn churn> > git stash > git stash apply -p <pick some things to have in working tree> > make test > git commit -a -m "First change!" > git stash apply -p <pick some more things> ...repeat... ? I could get behind that, and I personally like the index.
- magicalhippo 5y ago
  I haven't thought about the specifics, but yeah that looks like a very nice variant. Since Git has stash, it feels like my idea is mostly a frontend thing that shouldn't require much backend changes, if at all.
sagarm 5y ago
Seems equivalent to a git add -p # Review and stage git commit # Create commit git stash # Save uncommitted changes run_tests.sh # double-check git stash pop # or drop I'll do something like occasionally, but mostly I just rely on the CI to double-check me.
- gfxgirl 5y ago
  Yes, that is equivalent, except that you had to be aware of the staging area and its implications. CIs on large teams can't run fast enough to check every individual commit. They have to run them in bulk. So the CI will often not catch that of your 2 consecutive commits the first one breaks if the 2nd one fixes that break.
  - sagarm 5y ago
    I've also worked on large teams, and for us every published version of every change within our project is automatically tested. If your CI is too expensive to run on every commit it probably needs optimization -- something I've done myself a few times. Not investing time or resources into making your CI fast and reliable is a false economy IMO.
zoomablemind 5y ago
> ...I'd like to move my changes into a temporary area and then pick the lines into my working directory and commit that. One way to achieve this is by putting the changes into stash 'git stash push', then interactively grab the desired hunks from the stash into the work dir with 'git checkout --patch stash@{id}'. This will also add the accepted changes into the index, staging them for the commit. Kinda granular, but allows me to keep those nice verbose debugging parts yet out of commit.