3 ms·

I can’t build the staging area. I would much rather git stash -p the changes I don’t want to commit yet, and commit the workspace because that’s what I tested.

magicalhippo 6y ago
Yeah I want my actual files on disk to reflect what I'm about to commit. So ideally, IMHO, the staging area should work exactly in reverse of what it's currently doing.
- anarazel 6y ago
  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 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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.
- dinglejungle 6y ago
  The TortoiseGit client basically has this feature[1]. In the commit GUI, you can right click a file and select "Restore after commit", then you can edit the file to remove all the changes you don't want to commit (which means you can also test it, etc, and that your edits can be as granular as you want). Then, after you commit, it resets it to have all the changes you left out. I like it a lot. [1] https://stackoverflow.com/a/48788906 https://stackoverflow.com/a/48788906
professoretc 6y ago
I feel like a lot of the issues surrounding Git spring from its original insistence that the git repo exist in a subdirectory of your source directory, meaning that you can't have multiple checkouts in different directories. (I'm aware that you can do this now, with worktrees, but those are yet another distinct concept!) If the repo existed somewhere outside of your source directory, then a) the stash just becomes another directory (or directories), and b) so does the staging area. You could do anything with them (e.g., build, test) that you could do with any other directory of files.

magicalhippo 6y ago

Yeah I want my actual files on disk to reflect what I'm about to commit. So ideally, IMHO, the staging area should work exactly in reverse of what it's currently doing.

anarazel 6y ago
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 6y 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 6y 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 6y 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 6y 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 6y 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 6y 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.
dinglejungle 6y ago
The TortoiseGit client basically has this feature[1]. In the commit GUI, you can right click a file and select "Restore after commit", then you can edit the file to remove all the changes you don't want to commit (which means you can also test it, etc, and that your edits can be as granular as you want). Then, after you commit, it resets it to have all the changes you left out. I like it a lot. [1] https://stackoverflow.com/a/48788906 https://stackoverflow.com/a/48788906

professoretc 6y ago

I feel like a lot of the issues surrounding Git spring from its original insistence that the git repo exist in a subdirectory of your source directory, meaning that you can't have multiple checkouts in different directories. (I'm aware that you can do this now, with worktrees, but those are yet another distinct concept!) If the repo existed somewhere outside of your source directory, then a) the stash just becomes another directory (or directories), and b) so does the staging area. You could do anything with them (e.g., build, test) that you could do with any other directory of files.