Hacker News Reader

Comment by davidpfarrell | Hacker News Reader

> There is no staging area.

I don't actually want "No" staging area.

What I want is, once I "add" something, the file stays added.

Currently, I have `git st` alias setup :

    st = !git add -u && git status

This auto-updates the staging area for files that were previously staged.

So I get `git add` but also don't have to re-add anything manually from there ...

Since I do `git st` quite frequently, this works out for me ...

View on HN

That seems like the worst possible use of the staging there is, it creates overhead and complicates diffing for no value whatsoever.

If you want that behaviour, you can just `git commit -a` when you create your commit, then you only have to "git add" brand new unknown files.

Not really. I'm not sure I want it to behave the way GP suggests, but I definitely want to have staging, and `git commit -a` is basically an equivalent of having no staging.

The reasons for that are:

1. In the vast majority of cases there are multiple files I want to commit together. Usually I change them multiple times during the process.

2. It almost always starts with some debugging in a couple of other files, and I often want to keep that debugging for a couple of next commits, but `git checkout HEAD` these files in the end.

3. For me, the most popular way of using git rebase → edit (which I do reasonably often) is splitting a commit into 2 by separating files. This is easy enough by just changing a status of a file from "staged" to "modified" (I even have `git unstage` alias for that) and commiting.

So I kinda get why GP wants what he wants. This isn't crazy.

Now, that being said, I personally have absolutely no problems with how git does that now: I've figured out a workflow that solves these problems for me, and everything is ok now. This workflow is basically making many dozens of tiny commits to a branch without even bothering to name them properly, and then just doing `git rebase -i` many-many times while working on a single branch. So I just commit the code I don't intend to keep with a label "drop that", and drop these commits when I'm done. And other commits usually are heavily reordered and squashed into 3-5 larger commits that make some sense on a higher level (like 500 LOC of refactoring first, and then 1 LOC of an actual bug-fix, which usually makes much more sense than just 500 LOC of a bugfix, that solve the problem somehow, but it's absolutely not obvious how exactly). I rarely can figure out that separation before I'm done. In fact, I often fix the problem first, then refactor, then roll-back the fix just to add it again in a separate commit in the end (if the refactoring and the fix affect the same file, which also is often the case).

> Not really. I'm not sure I want it to behave the way GP suggests, but I definitely want to have staging

So I'm replying to OP's very specific usage pattern, and you object with a completely different usage pattern?

> `git commit -a` is basically an equivalent of having no staging.

GP doesn't use the staging as a staging, since they immediately stage all modified files. That means the staging is useless, they can just commit files straight from modified. Which is what `git commit -a` does.

> 1. In the vast majority of cases there are multiple files I want to commit together. Usually I change them multiple times during the process.

OK? `git commit -a` doesn't preclude that. You just use it instead of `git commit`.

> 2. It almost always starts with some debugging in a couple of other files, and I often want to keep that debugging for a couple of next commits, but `git checkout HEAD` these files in the end.

I'm really happy for you. It doesn't work when the files are already staged, which is the case of GP.

> 3. For me, the most popular way of using git rebase → edit (which I do reasonably often) is splitting a commit into 2 by separating files. This is easy enough by just changing a status of a file from "staged" to "modified" (I even have `git unstage` alias for that) and commiting.

https://sapling-scm.com/docs/commands/uncommit

> uncommit part or all of the current commit

You don't need a staging area to craft commits, you can manipulate the tip commit directly. With good enough support for that (which sapling seems to have inherited from mercurial), the staging is just an unnecessary pseudo-commit.

This would break the workflow of using the staging area to break a larger change into smaller commits.

git add -p

Allows you to select hunks of changes and stage them for committing...

For GP's use case, its "added some stuff, want to stage the stuff I modified since then to those files"... which I feel is a perfectly normal workflow.

There's nothing saying that one can't add chunks to the staging area and then immediately commit it without invoking that alias afterwards (since it is a very deliberate "add these things" rather than "adding a bunch of things and keep adding."

> git add -p

git commit -p achieves the same, but avoids explicitly using the staging area.

Reply on news.ycombinator.com