4 ms·

While I agree that git could use a rethink from a user tooling perspective, I really appreciate the existence of the index. I’m not tied necessarily to this spe

While I agree that git could use a rethink from a user tooling perspective, I really appreciate the existence of the index. I’m not tied necessarily to this specific implementation of it, but having a staging area where chunks are added piecemeal is an enormous benefit. I honestly wish git forced `-p` for operations that support it. I’ve worked on too many teams where people would just commit everything in their working directory, and it would inevitably make reviewing their PRs a nightmare. Particularly with times where changes were accidentally committed wholesale that shouldn’t have been part of that set of changes.

skrebbel 5y ago
I'm not opposed to carefully crafting a good commit, I'm opposed to a state-heavy, badly named, inconsistent feature to do it. And if you use any decent git UI (including -p on the CLI), you don't really need it to be that persistent very often. It could just be a list of chunks to select in the "make commit" window, which is of course exactly how most git UIs "make commit" window looks. It's a single step then, no intermediary persistent state (with three names). JJ seems to workaround this in the other direction, by making the concept of commits and rebases much more lightweight, which i think is a refreshing enough take that I'd like to try it.
pjc50 5y ago
> just commit everything in their working directory But that's what they've tested. I've had far more problems in the other direction, where the commit doesn't contain the complete set of things that it's supposed to but because all the tooling - every single IDE and compiler - is looking at the working directory not the index, I've missed something. The index is definitely confusing for new users and users of other VCS. > having a staging area where chunks are added piecemeal is an enormous benefit. It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Then you'd see the top-level work item as a "commit" and the individual changes as "subcommits".
- stouset 5y ago
  Like I said, I’m not sold on git’s specific implementation. But breaking things into smaller, focused commits is—in my experience—a hallmark of good development practice. There should absolutely be better tooling around it, so that these piecemeal commits can be tested in isolation from one another. That’s a far better approach than just throwing up our hands and committing everything in the working tree, even if half of it has nothing to do with what’s intended.
  - jefftk 5y ago
    jj split?
  - treadmill 5y ago
    How do you even end up in that situation? If you start a new feature or bugfix having random local changes lying around, you are _already_ doing it wrong. Start a feature branch, do clean commits of the current state, test, push, review, merge.
  - pjc50 5y ago
    > if half of it has nothing to do with what’s intended. Perhaps the focus should then be on making it easier to get that junk out of the working tree? Better stashing?
- throw0101a 5y ago
  > It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Then you'd see the top-level work item as a "commit" and the individual changes as "subcommits". Would something like Mercurial's queues be something what you're looking for? * https://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ https://stevelosh.com/blog/2010/08/a-git-users-guide-to-merc... See especially "…with Two (or More) Patches" onwards.
- feanaro 5y ago
  > But that's what they've tested. https://pre-commit.com/ https://pre-commit.com/ helps with that. > It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Yes! I've been saying this for years. Branch merge commits are already this, kind of. However their UI sucks and there's an idea gap which prevents them from being fully understood as such "supercommits" composed of subcommits. For one, the user should be forced to give meaningful, high level commit messages for merge commits and the tooling should fold commits made on a merge branch into the merge commit by default (effectively linearizing the merged history).
Hendrikto 5y ago
> I’ve worked on too many teams where people would just commit everything in their working directory, and it would inevitably make reviewing their PRs a nightmare. And they always claim to review and clean their commits before pushing, or at least before merging, but never do.

skrebbel 5y ago

I'm not opposed to carefully crafting a good commit, I'm opposed to a state-heavy, badly named, inconsistent feature to do it. And if you use any decent git UI (including -p on the CLI), you don't really need it to be that persistent very often. It could just be a list of chunks to select in the "make commit" window, which is of course exactly how most git UIs "make commit" window looks. It's a single step then, no intermediary persistent state (with three names). JJ seems to workaround this in the other direction, by making the concept of commits and rebases much more lightweight, which i think is a refreshing enough take that I'd like to try it.

pjc50 5y ago

> just commit everything in their working directory But that's what they've tested. I've had far more problems in the other direction, where the commit doesn't contain the complete set of things that it's supposed to but because all the tooling - every single IDE and compiler - is looking at the working directory not the index, I've missed something. The index is definitely confusing for new users and users of other VCS. > having a staging area where chunks are added piecemeal is an enormous benefit. It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Then you'd see the top-level work item as a "commit" and the individual changes as "subcommits".

stouset 5y ago
Like I said, I’m not sold on git’s specific implementation. But breaking things into smaller, focused commits is—in my experience—a hallmark of good development practice. There should absolutely be better tooling around it, so that these piecemeal commits can be tested in isolation from one another. That’s a far better approach than just throwing up our hands and committing everything in the working tree, even if half of it has nothing to do with what’s intended.
- jefftk 5y ago
  jj split?
- treadmill 5y ago
  How do you even end up in that situation? If you start a new feature or bugfix having random local changes lying around, you are _already_ doing it wrong. Start a feature branch, do clean commits of the current state, test, push, review, merge.
- pjc50 5y ago
  > if half of it has nothing to do with what’s intended. Perhaps the focus should then be on making it easier to get that junk out of the working tree? Better stashing?
throw0101a 5y ago
> It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Then you'd see the top-level work item as a "commit" and the individual changes as "subcommits". Would something like Mercurial's queues be something what you're looking for? * https://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/ https://stevelosh.com/blog/2010/08/a-git-users-guide-to-merc... See especially "…with Two (or More) Patches" onwards.
feanaro 5y ago
> But that's what they've tested. https://pre-commit.com/ https://pre-commit.com/ helps with that. > It would be quite fun if we could have hierarchical commits, so I could add bits to a commit without having to squash/amend. Yes! I've been saying this for years. Branch merge commits are already this, kind of. However their UI sucks and there's an idea gap which prevents them from being fully understood as such "supercommits" composed of subcommits. For one, the user should be forced to give meaningful, high level commit messages for merge commits and the tooling should fold commits made on a merge branch into the merge commit by default (effectively linearizing the merged history).

Hendrikto 5y ago

> I’ve worked on too many teams where people would just commit everything in their working directory, and it would inevitably make reviewing their PRs a nightmare. And they always claim to review and clean their commits before pushing, or at least before merging, but never do.