Hacker News Reader

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.

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

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.

> The only two alternatives I can imagine are worse: disallowing partial commits (I use this feature all the time; I guess I could replace it by a temp commit on a branch and then so long as cherry-pick -p still exists, use that) or specifying it to git-commit (that would be one gnarly set of flags…)

Are you aware that git commit --amend exists? That replaces anything I might ever be tempted to use the staging area for.

I'm not sure how you use --amend to do partial commits of a file.

Well, that would be solved with --interactive, would it not?

"git commit" takes the -p (or --patch) flag for partial commits of a file, just like "git add". (Some people prefer --interactive, but I think the patch mode is significantly superior.)

There's a good chance the person you are replying uses git commit --amend all the time to modify commits in conjunction with git add -p.

No, hg amend -i is much worse than git add -p. I do that when I have to use mercurial and there's significantly more mental overhead to make sure I'm not accidentally modifying a commit I did not intend to modify. Creating a "temporary" commit before I have a complete change is also annoying.

And once you need to add a file, you're back to having a staging-like concept.

IMO the staging area is fundamental complexity.

Perhaps it's a difference in workflow, but I really don't understand why managing a "temporary" commit is so mentally taxing. Especially because in my workflows, I'm often not managing a single commit but an entire stack of commits, for which the staging area adds no value.

As I see it, the staging area is useless because it's basically a weird not-quite-commit-thing that you are more or less required to deal with (no way to opt out of it--several commands end up mucking about with the staging area even if you're not trying to use it). It feels like the better way to model it is to make it an actual commit, let it be manipulated as a regular commit, and then potentially improve the tooling around manipulating unpublished head commits as well.

Agreed. If you want to commit something that's not "reviewable" yet, just put it on another branch. Get used to committing things that aren't done yet! Hg does it right.

OK, then rebase and squash after making a bunch of commits. I can see why someone might like staging, but clearly it can be built on top of other git functions.

So, sorry, staging being "fundamental complexity" sounds petty BS to me. You like it, and that's fine, but it's in no way fundamental. I've used git for a long, long time, tried staging a few times and have never reached for it again.

What about hg add (or git add)? Does that not "stage" an addition for the next commit?

So I'm working and committing as I go along instead of staging, I need to be super sure I only rebase and never pull or else I've made a huge mess?

I think I'll stick with staging.

For me the staging area is almost the most important feature of git. I often use it to stage new code that already and then step by step add more code that works.

This only works if you use a GUI like Sourcetree . With the command like staging isn’t much fun.

I use the git command line almost exclusively and find it preferable to other tools for manipulating the staging area.

I have repeatedly tried to use it with the command line but I just can't get the hang of it.

Which part gives you issues, adding things or removing things?

Working at file granularity is fine, but I've never gotten a good workflow for using the CLI to stage individual hunks. Nothing beats selecting the lines I care about in magit (or any other GUI) and clicking to stage.

git add --interactive <file>, then mark the file as staged and select the patch option if memory serves. It's not complex once you get the hang of it. The only problem I run into is not being able to split chunks further.

I do agree a GUI lowers the barrier to entry.

Use git add -p <file>

And you'll go straight to the patch option. Then you can split the chunks further, and for hunks that can't be split further, you can edit them and add/remove lines from the hunk as needed.

Thanks, didn't know about that shorthand!

The way it’s displayed and then also the commands. With Sourcetree you have a really nice display and it’s very efficient to stage/upstage/discard lines and hunks. I am sure I could get used to the command line with enough practice but source control tools are pretty low on my list of priorities of things I want to get better with. So I stick to what works for me.

I set PyCharm's Git client to auto-stage everything, and build up my commits using PyCharm's tools. You can go through your visual diff and hit checkboxes to say "put this chunk in the commit, exclude this chunk". Or you can get one piece of your commit ready, then create a new Changeset and have any new changes go into that changeset, able to be reviewed, committed, shelved, or rolled back separately.

The problem with staging is I want every file I changed in one place so I can notice what changed and look through the diff together. Not to just show up at the bottom of the list .

I recently switched from gitk to qgit as my always-open repo status tool, and qgit doesn't show staged/unstaged changed separately like gitk. As a result, using the staging area suddenly has higher friction.

What I found myself doing is using a plain old commit instead of a staging area. Where I would previously build a commit in the staging area before I finally create it, I now simply keep amending it until it suits my need. It oftens starts out with a message like "WIP". This also scales to building multiple commits (use --fixup instead of --amend, and checkout instead of stash).

In practice the workflow is very similar and I was surprised by how little the removal of a core feature that I used all the time actually affects me.

If you think the staging area is unintuitive you should see what emacs magit does( and I love emacs magit). You stage A, start typing a commit message, stage B, finish the commit message, commit, and lo and behold B isn’t in the commit. So in magit it feels like there’s a secret second staging area.

Magit brings an immense clarity to git workflows; I suspect I would not rely on staging as heavily as I do, if it weren't for Magit.

If anything, I kind of wish git had as many named stages as you wanted.

Its one of the nice features of Perforce but they screw it up by only allowing separation at the whole file level.