8 ms·

That's kinda the point, though. I don't want to run a single command to both define and complete the commit. I want to be able to do it in steps. Review my m

That's kinda the point, though. I don't want to run a single command to both define and complete the commit. I want to be able to do it in steps. Review my modified files, pick and choose what's staged, maybe make some more edits, stage those, double-check the staged diffs, verify the commit has what I want, and _then_ hit the button.

krupan 10y ago
You make it sound like a commit is some final immutable set-in-stone thing and so you need staging area. Commits are only "set in stone" after you share (push) them with others.
- acemarke 10y ago
  You're still missing my point. My preferred workflow is to iteratively put together the pieces I want, and only hit the "commit" button when I'm pretty sure I've got it crafted the way I want. Sure, I _can_ rebase, amend, and rewrite commits after creating them, assuming I haven't pushed them yet, but I'd much rather do it _before_ the commit is created. At first glance, this "gitless" tool doesn't seem to really support that workflow.
  - derefr 10y ago
    Why, though? What's the difference between a staging area that you convert into a commit, and an initially-empty commit that acts as a staging area, that you "commit" by just not modifying it any more, and instead creating a new empty commit (new staging area) to work in? They're bijective mappings of the same data, with the same actions triggered at the same points in a workflow. The only difference is what you label the actions. To go further: how do you feel if you think of all your un-pushed commits as simply "a chain of staging areas"? What if "committing" was something that happened at git-push time, and until then, you just created staging-area after staging-area and populated them with patch-chunks? Because this would also be a bijective mapping, involving the same actions in the same places.
    - lukeschlather 10y ago
      My commit workflow goes like this: I run git diff, look at the first file that has changed, and then if it looks good, I add that file. At this point I may notice a stray print() statement or something, and delete it, then hit add. I rinse and repeat until I've read everything that I'm about to commit and verified it's what I want. I've been using mercurial for a couple months for work, and I miss the git staging area workflow. I dislike just assuming all the modifications I've made are good to go, I think the focus git's staging area steers you toward is really valuable.
      - bendbro 10y ago
        Did you reply to the wrong comment? Your comment seems off topic relative to the parent. Regardless, your workflow of 'git diff' on staging with 'add's functions the same as 'git diff HEAD~' on a commit with 'commit --amend's
        lukeschlather 10y ago
        I think you (and the parent) are totally misunderstanding what I and probably most other people use git's staging area for if you think that git diff HEAD~ does the same thing. To illustrate a little more explicitly, a typical workflow goes like this: git diff git add file1 git diff git add file2 git diff ... git commit Now yes, you could replace `git add fileX` with `git commit --amend fileX` but I don't see that as a better interface. There are lots of circumstances where I rewrite history, but if there's a workflow that doesn't involve rewriting history, I'll take that one please.
        tene 10y ago
        To make this point a little more directly, and in a similar way to what the article talks about, using "git commit" for this is using the same command for two different things, and makes it easier to make mistakes. Treating the staging area differently from commits means that you'll never accidentally alter a commit that has already been pushed, or accidentally add changes to a commit that you didn't intend them to be in. Yes, you can implement this workflow with commit --amend, but it's nice to have support from the tools to distinguish between "possibly-incomplete changes that I've signed off on as part of preparing a larger change set" and "completed, approved changes that may have been pushed to other people". Yes, you can implement this by committing each change and then later rebasing them, but that's even worse from a perspective of the tools supporting the workflow directly.
- makomk 10y ago
  Which means that if you amend commits, you need to keep track of whether or not you've shared them with others yet.
  - krupan 10y ago
    Which mercurial does for you (see: phases), but you are right, I forget that git does not help you there.
david-given 10y ago
But isn't this what changelists do? I've certainly done pretty much what you describe in hg, svn and Perforce, which don't have staging areas. Also, if you end up committing only parts of files, then how do you know that what you commit works?
- prodigal_erik 10y ago
  This. I can't test the staging area so I have zero interest in committing it. Actually I have less than zero interest; I would like my team to be prevented from ever creating untested commits.
  - parenthephobia 10y ago
    This isn't an argument against using staging areas, but against creating untested commits. If your workflow is that every commit must be tested, the correct approach is to enforce that rule, rather than banning an only tangentially related feature.
    - prodigal_erik 10y ago
      Does the staging area have any use other than creating a commit that differed from the workspace, which guarantees that it cannot have been tested?
      - Mithaldu 10y ago
        Its use is to help in reasoning about the changes by offering an easy way to diff staging to the previous commit and to hdd, while being easy to change quickly. As for testing, it is trivial to stash or commit your current changes, go go the commit just made, test it, then carry on. A commit having been made partial only guarantees it wasn't tested if the developer is bad.
        prodigal_erik 10y ago
        To me that sounds harder than making a known-good commit of my entire workspace, and refactoring that commit into several by selectively applying it to a clean workspace (this doesn't need to be done at the same time or by the original author).

krupan 10y ago

You make it sound like a commit is some final immutable set-in-stone thing and so you need staging area. Commits are only "set in stone" after you share (push) them with others.

acemarke 10y ago
You're still missing my point. My preferred workflow is to iteratively put together the pieces I want, and only hit the "commit" button when I'm pretty sure I've got it crafted the way I want. Sure, I _can_ rebase, amend, and rewrite commits after creating them, assuming I haven't pushed them yet, but I'd much rather do it _before_ the commit is created. At first glance, this "gitless" tool doesn't seem to really support that workflow.
- derefr 10y ago
  Why, though? What's the difference between a staging area that you convert into a commit, and an initially-empty commit that acts as a staging area, that you "commit" by just not modifying it any more, and instead creating a new empty commit (new staging area) to work in? They're bijective mappings of the same data, with the same actions triggered at the same points in a workflow. The only difference is what you label the actions. To go further: how do you feel if you think of all your un-pushed commits as simply "a chain of staging areas"? What if "committing" was something that happened at git-push time, and until then, you just created staging-area after staging-area and populated them with patch-chunks? Because this would also be a bijective mapping, involving the same actions in the same places.
  - lukeschlather 10y ago
    My commit workflow goes like this: I run git diff, look at the first file that has changed, and then if it looks good, I add that file. At this point I may notice a stray print() statement or something, and delete it, then hit add. I rinse and repeat until I've read everything that I'm about to commit and verified it's what I want. I've been using mercurial for a couple months for work, and I miss the git staging area workflow. I dislike just assuming all the modifications I've made are good to go, I think the focus git's staging area steers you toward is really valuable.
    - bendbro 10y ago
      Did you reply to the wrong comment? Your comment seems off topic relative to the parent. Regardless, your workflow of 'git diff' on staging with 'add's functions the same as 'git diff HEAD~' on a commit with 'commit --amend's
      - lukeschlather 10y ago
        I think you (and the parent) are totally misunderstanding what I and probably most other people use git's staging area for if you think that git diff HEAD~ does the same thing. To illustrate a little more explicitly, a typical workflow goes like this: git diff git add file1 git diff git add file2 git diff ... git commit Now yes, you could replace `git add fileX` with `git commit --amend fileX` but I don't see that as a better interface. There are lots of circumstances where I rewrite history, but if there's a workflow that doesn't involve rewriting history, I'll take that one please.
        tene 10y ago
        To make this point a little more directly, and in a similar way to what the article talks about, using "git commit" for this is using the same command for two different things, and makes it easier to make mistakes. Treating the staging area differently from commits means that you'll never accidentally alter a commit that has already been pushed, or accidentally add changes to a commit that you didn't intend them to be in. Yes, you can implement this workflow with commit --amend, but it's nice to have support from the tools to distinguish between "possibly-incomplete changes that I've signed off on as part of preparing a larger change set" and "completed, approved changes that may have been pushed to other people". Yes, you can implement this by committing each change and then later rebasing them, but that's even worse from a perspective of the tools supporting the workflow directly.
makomk 10y ago
Which means that if you amend commits, you need to keep track of whether or not you've shared them with others yet.
- krupan 10y ago
  Which mercurial does for you (see: phases), but you are right, I forget that git does not help you there.

david-given 10y ago

But isn't this what changelists do? I've certainly done pretty much what you describe in hg, svn and Perforce, which don't have staging areas. Also, if you end up committing only parts of files, then how do you know that what you commit works?

prodigal_erik 10y ago
This. I can't test the staging area so I have zero interest in committing it. Actually I have less than zero interest; I would like my team to be prevented from ever creating untested commits.
- parenthephobia 10y ago
  This isn't an argument against using staging areas, but against creating untested commits. If your workflow is that every commit must be tested, the correct approach is to enforce that rule, rather than banning an only tangentially related feature.
  - prodigal_erik 10y ago
    Does the staging area have any use other than creating a commit that differed from the workspace, which guarantees that it cannot have been tested?
    - Mithaldu 10y ago
      Its use is to help in reasoning about the changes by offering an easy way to diff staging to the previous commit and to hdd, while being easy to change quickly. As for testing, it is trivial to stash or commit your current changes, go go the commit just made, test it, then carry on. A commit having been made partial only guarantees it wasn't tested if the developer is bad.
      - prodigal_erik 10y ago
        To me that sounds harder than making a known-good commit of my entire workspace, and refactoring that commit into several by selectively applying it to a clean workspace (this doesn't need to be done at the same time or by the original author).