Evans: Confusing git terminology [LWN.net]

Evans: Confusing git terminology

Posted Nov 2, 2023 23:41 UTC (Thu) by roc (subscriber, #30627)
In reply to: Evans: Confusing git terminology by tamiko
Parent article: Evans: Confusing git terminology

The staging area is unnecessary complexity. It's completely superfluous.

to post comments

Evans: Confusing git terminology

Posted Nov 3, 2023 1:53 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (14 responses)

Hmm. I use the stage all the time. I use it to make unit commits out of the current state of my worktree. I can't imagine having to untangle all of that with post-commit logic when I can instead craft a patch, make a commit and inspect the diff in the editor (`git config --global commit.verbose true`) to make sure it meets my needs. If I instead had to development in the exact order that makes sense as a commit series (or deal with conflicts when reordering them)…I feel I would lose a lot of expressiveness in how a topic gets put together because of how much more planning and time it would take to do so.

But yes, if you're using a workflow where things just get `git commit -m 'address comments'` and squash-merged at the end, the stage isn't really all that useful. But to say that it is "completely superfluous" is too far IMO.

Evans: Confusing git terminology

Posted Nov 3, 2023 2:41 UTC (Fri) by roc (subscriber, #30627) [Link]

git commit -p is an okay solution, although hg commit -i is a lot better.

There is no fundamental reason why working with commits has to be harder than working with the staging area. git sometimes makes it harder, but that is unnecessary complexity.

Evans: Confusing git terminology

Posted Nov 3, 2023 8:49 UTC (Fri) by pm215 (subscriber, #98099) [Link] (5 responses)

If git made it easier to work with existing commits (reordering them, nipping back 'up' in the series to add something earlier, etc) you wouldn't need 'staging', because it could just be the current top commit. I use 'stgit' which *does* provide that patch-series UI on top of raw git and I find that it's a lot nicer and once you do 'staging' only gets in the way and confuses.

Evans: Confusing git terminology

Posted Nov 5, 2023 7:07 UTC (Sun) by NYKevin (subscriber, #129325) [Link]

The immensely frustrating part is that Mercurial already does most or all of those things (some of them are ostensibly "experimental" or off by default, but Google and Facebook have been using the changeset evolution stuff for years now).

Yes, I understand, Git is the de facto standard, we're not all going to switch now, etc. But can't Git at least steal some good ideas from the competition?

Evans: Confusing git terminology

Posted Nov 7, 2023 7:54 UTC (Tue) by marcH (subscriber, #57642) [Link]

> I use 'stgit' which *does* provide that patch-series UI on top of raw git and I find that it's a lot nicer and once you do 'staging' only gets in the way and confuses.

I uses magit that provides a comparable UI on top of raw git and the index is still extremely useful. It's useful to slowly prepare a commit out of all the work in progress of course; that's the main purpose of the index after all. When you're in the kitchen cooking, you never just throw everything that's in front of you into the pan.

But where the index is probably the most impressive is when moving hunks across commits:

1. First key stroke applies the opposite of a hunk (from any "source" commit) to the index and to the index only.
2. Second key stroke performs an "instant fixup" on that commit.

=> At this stage the hunk has been removed from the git history while the actual file never changed at all. All thanks to the index!

3. Now the file is different from the git history, so stage the hunk and perform an "instant fixup" on the "destination" commit.

Done. It's magital!

Of course it does not have to be that coarse-grained; you can do the same with any line range.

Evans: Confusing git terminology

Posted Nov 7, 2023 8:35 UTC (Tue) by SLi (subscriber, #53131) [Link] (2 responses)

I also use stgit (since a few weeks ago), and it does feel like it makes things easier. With that workflow, the staging area mostly hinders my work, forcing me to do `git add -u .` sometimes when a commit hook has done some cleanup and stgit refuses to `stg refresh` because the index is dirty.

Changeset evolution is something I'm not familiar with, but it sounds really neat. It's clear to me that stgit still doesn't give me what something like Gerrit does; force pushing is too primitive of an operation, with, I guess, too little semantics of "this means a new revision".

Evans: Confusing git terminology

Posted Dec 2, 2023 23:12 UTC (Sat) by pm215 (subscriber, #98099) [Link] (1 responses)

I usually use "stg refresh --force" for the "something has unhelpfully put something in the index, just put it in the patch" task. Luckily it doesn't happen often.

Evans: Confusing git terminology

Posted Dec 3, 2023 7:37 UTC (Sun) by SLi (subscriber, #53131) [Link]

I think it happens every time when a commit is aborted because of a pre-commit hook. It happens a lot to me because I run a linter there.

Evans: Confusing git terminology

Posted Nov 3, 2023 12:35 UTC (Fri) by dezgeg (guest, #92243) [Link] (6 responses)

If staging area was something completely optional only for those who want to make partial commits it'd be more palatable. I use is for partial commits myself as well, but I hate that everyone needs to get exposed to it at the very least when git add'ing new files or during conflict resolution.

Evans: Confusing git terminology

Posted Nov 3, 2023 16:00 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

I do agree that a new git-native frontend for committing would be useful to skip the stage (I've come to use `vim-fugitive` more than `git add -p` myself over the years; I'm sure Magit, VSCode plugins, and other tools exist), but tossing it out is…excessive.

Evans: Confusing git terminology

Posted Nov 3, 2023 20:32 UTC (Fri) by roc (subscriber, #30627) [Link] (4 responses)

You don't need the staging area to make partial commits! Even git has `commit -p`!

Evans: Confusing git terminology

Posted Nov 3, 2023 20:49 UTC (Fri) by mbunkus (subscriber, #87248) [Link] (3 responses)

Patch committing isn't coming close to being a replacement for the staging area. The staging area gives you all the freedom to spread the patch selection out over as much time as you want to. I often stage hunks on one work day & stage some more the next, only actually committing on the day after. This nicely allows me to temporarily focus on other parts of the code, other aspects, and slowly assemble the changes I actually want to group together into a single commit.

Having proper tooling that makes it a breeze to stage, unstage anything from single modified lines over patch hunks to full files & even ranges of files is rather important here in order to fully enjoy having a staging area. In my case this is Emacs package Magit, easily the most important element of my tool case. There are other great solutions, too.

Of course working without the staging area should ideally be a lot easier than it is now for all those cases where it isn't really needed, or where users want to adopt workflows without it. But the staging area is not a mistake, it's not superfluous, it shouldn't be abolished.

Evans: Confusing git terminology

Posted Nov 3, 2023 21:20 UTC (Fri) by roc (subscriber, #30627) [Link] (2 responses)

> I often stage hunks on one work day & stage some more the next, only actually committing on the day after. This nicely allows me to temporarily focus on other parts of the code, other aspects, and slowly assemble the changes I actually want to group together into a single commit.

You can do this with temporary commits that you later collapse into the actual commit you want.

Working with the staging area over a long period of time is actually one of its great weaknesses. It doesn't stick to the branch so if you need to temporarily work on something else, you have to save your work as a temporary commit anyway.

> Having proper tooling that makes it a breeze to stage, unstage anything from single modified lines over patch hunks to full files & even ranges of files is rather important here in order to fully enjoy having a staging area.

Moving changes between commits can be too painful in git today and that's a good reason for preferring the staging area over temporary commits --- in git today. BUT moving changes between commits is important in its own right; VCSs need good support for it, and if you have good support for it, that reason for using the staging area goes away.

> But the staging area is not a mistake, it's not superfluous, it shouldn't be abolished.

It's not going to be abolished because obviously everyone's muscle memory depends on it, including my own. Exposing it in the UI was not a mistake at the time, since it was more expedient than building all the tooling that makes it obsolete. But it's definitely a suboptimal design choice at this point.

Evans: Confusing git terminology

Posted Nov 4, 2023 9:59 UTC (Sat) by mbunkus (subscriber, #87248) [Link] (1 responses)

I think we're arguing from two slightly different view points. If I understand you correctly, you're arguing that the staging area is _conceptually_ superfluous as the benefits it provides _could_ be implemented better/differently (but mostly haven't yet). From that point of view "The staging area is unnecessary complexity. It's completely superfluous." (quoting you here) makes sense.

I'm arguing that from _how things are today_ the staging area provides a very valuable service that cannot be expressed by other functionality _that exists already_. From this point of view "The staging area is unnecessary complexity. It's completely superfluous." seems very wrong.

Would that be a fair interpretation? If so, I don't actually disagree with you.

Evans: Confusing git terminology

Posted Nov 5, 2023 0:37 UTC (Sun) by roc (subscriber, #30627) [Link]

That's right, thanks for clarifying!

Evans: Confusing git terminology

Posted Nov 3, 2023 10:31 UTC (Fri) by intelfx (subscriber, #130118) [Link] (7 responses)

> The staging area is unnecessary complexity. It's completely superfluous.

Maybe for you it is, but please refrain from making blanket statements like this :-)

Evans: Confusing git terminology

Posted Nov 3, 2023 20:43 UTC (Fri) by roc (subscriber, #30627) [Link] (6 responses)

It's a big mistake to assume that a feature is essential or good design just because one is used to using it.

I myself use 'git add' out of habit, but there's no reason why git couldn't have something as powerful as `hg commit -i`, hide the staging area from users completely, and add some conveniences to make it easier to work with the topmost commit like you work with the staging area. That would be a simpler, more powerful and easier-to-use system. Gitless is a lot like this.

Evans: Confusing git terminology

Posted Nov 7, 2023 8:08 UTC (Tue) by marcH (subscriber, #57642) [Link] (5 responses)

> and add some conveniences to make it easier to work with the topmost commit like you work with the staging area

The staging area does indeed feel like a "light-weight commit". Was that really necessary? Hard to tell because I'm so used to it but for instance I'm not sure I would like the output of "git describe" to be changing all the time. This would also mean creating commits very rarely and "amending" most of the time... would that really be more intuitive?

Interestingly, while the existence of the "staging area" is debatable it's one of the few things that has a clear and unambiguous name :-)

Evans: Confusing git terminology

Posted Nov 7, 2023 9:29 UTC (Tue) by roc (subscriber, #30627) [Link]

> Interestingly, while the existence of the "staging area" is debatable it's one of the few things that has a clear and unambiguous name :-)

Unfortunately it also has two other names, "the cache" and "the index", so unfortunately I can award no points.

Evans: Confusing git terminology

Posted Nov 7, 2023 10:08 UTC (Tue) by kleptog (subscriber, #1183) [Link] (3 responses)

> The staging area does indeed feel like a "light-weight commit". Was that really necessary?

There are things that make the index different from a light-weight commit:

* It can store conflicts. If your merge aborts due to a conflict, the staging area can record that
* It doesn't have a commit message

As such it doesn't have a tree-ish or commit hash which represents its state, so it can't be shared. Though I guess that could be invented if necessary.

For me anyway, the workflow: "assemble the changes you want to commit, then think of a commit message" feels far more natural than "think of a commit message, then decide what goes in it". I often have changes in my repo that I don't want to commit. I've worked with "hg mq" and git was a breath of fresh air by comparison.

Evans: Confusing git terminology

Posted Nov 7, 2023 10:26 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

If you were doing a "git 2.0" redesign, you'd want commits to be able to store unresolved conflict state, and you'd want commit messages to be optional, at which point the index is just another commit.

And hg mq had a lot of issues; it was, more or less, an attempt to port the "quilt" way of working with patch series directly into a VCS; I'm not surprised that you found using the VCS operations more intuitive. The interesting comparison point is with hg evolve, where you are encouraged to commit often, and construct the final stack of changes when you've finished working; when I used Mercurial at work, I had a setup that did hg commit -m"WIP at $(date)" to store my latest work, and used the Changeset Evolution toolset (hg uncommit, hg rebase, hg amend, hg metaedit, hg evolve, hg fold and hg split) to reassemble my pile of code into a stack of reviewable commits.

Evans: Confusing git terminology

Posted Nov 7, 2023 19:52 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)

> it was, more or less, an attempt to port the "quilt" way of working with patch series directly into a VCS

stgit, magit, quilt, git pile, git series,...

I really hope git will one day provide better built-in support for volatile commits so not everyone and their dog re-invents more or less the same features and we end up with so much fragmentation.

The very first, baby step is awareness: giving these commits a _name_ (and not 3 different names like the index, *sigh*). "Volatile" is obviously and objectively better than the ugly "re-baseable" :-)

Evans: Confusing git terminology

Posted Nov 8, 2023 21:10 UTC (Wed) by marcH (subscriber, #57642) [Link]

To be fair we got `git range-diff` in 2018, that was significant. But only after Gerrit did it in 2017 and "git series" in 2016.

Gitlab said they're looking at it: https://gitlab.com/gitlab-org/gitlab/-/issues/24096

GitHub will never use that "2nd dimension", their model is single commit per Pull Request, then fixup commits are NOT squashed but used for tracking patch revisions and review progress instead: https://github.com/zephyrproject-rtos/zephyr/issues/39194. At least they've looked at the problem and done something about it.

Back to the main topic: like it or not, GitHub has done a lot to simplify git and make it popular. It comes at a price for "grey beards" :-)