Hacker News Reader

Comment by magicalhippo | Hacker News Reader

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.

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.

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.

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.

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.

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.

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.

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.

> ...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.

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

Reply on news.ycombinator.com