10 ms·

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

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).
    - slavik81 10y ago
      I worked for many years with version systems that didn't include staging. People still frequently forgot to commit necessary files. Opinions may differ, but I feel the best place to enforce that constraint is with a CI server that merges only working changes.
      - prodigal_erik 10y ago
        This is a symptom of offering an option to perform an incomplete commit. Word processors don't have this problem because they don't make you specify which paragraphs are important enough to save. I commit the workspace. If I'm not happy with some of the workspace, I fix it (or stash it for later when chaos happens).
    - parenthephobia 10y ago
      If you're trying to enforce tested commits without running tests on what's actually committed, you're doing it wrong. There's an inherent incompatibility between the supposed ways that the staging area can be replaced with other things. If you replace it with a commit you keep amending as you go, but also all commits must pass tests, then you can never commit partially complete code, which defeats the purpose of having the amending commit. If you interactively choose what to commit at commit time, then you run the risk of failing the test and then, after fixing whatever was wrong, having to remember which parts of which files it was you chose to commit last time. Now, you could choose to have your CVS remember that for you, but then you're basically reinventing a less-capable version of the staging area. If you simply commit everything, then you can never have any code in your working tree which breaks tests, nor can you have code which isn't logically part of the commit you're currently working on. In practice that means that when you find things that need fixing that aren't directly related to what you're doing, you either fix it and commit it with unrelated changes - which interacts poorly with merging or reverting those commits - or you don't fix it and, most probably, forget about it.
    - kcburge 10y ago
      The staging area is extremely helpful, beyond just making a single selective/partial commit. Other uses: 1. Breaking a large commit into multiple smaller commits. 2. As a simple "review" system. You stage files that have been reviewed so you know you don't have to look at them again, while continuing on a change. 3. Cleaning the working copy of superfluous changes/files. If you stage the files you want to keep, then clean and/or checkout force, it wipes out the files you didn't stage. Then just reset to unstage all files and continue making changes. 4. Splitting a branch into two different branches, when you realize that a branch could be broken down into smaller separate changes that are both incomplete, but COULD be committed separately. You merge squash to master, staging and commit creating a new branch for feature1, then stage, stash, and stash pop the rest back on to master (since sometimes you cannot just switch back to master), and create the feature2, and feature3 branches, etc. I also use Magit in Emacs, which makes the staging area like the swiss army knife of Git. I cannot image the amount of extra pointless tedious work that would be required using commits, branches, and merges to simulate the equivalent behavior of the staging area. The staging area is used heavily by folks who like to get a lot of things done with minimal effort required. I understand the difficulty for new users switching to Git, and I agree that the commands could be more clear and consistent, but beginner (commit all) and novice (selective commit) users should not be left to determine the utility of Git features they very likely do not fully understand or appreciate.
      - e12e 10y ago
        > 2. As a simple "review" system. You stage files that have been reviewed so you know you don't have to look at them again, while continuing on a change. (How) does this work if you want/need a virtual paper trail of reviews and/or in a distributed team? Do you email your changes for review, without making a commit and push (to a branch and/or fork)? Apologies if I misunderstand what you mean, but I read "review" here as colleague walks by and have a look, and says lgtm?
        kcburge 10y ago
        This is personal review, not peer review. I try to review my code after completion and a period of rest before submitting for peer review. This discipline finds a surprising number of issues with my code that I just didn't see when I was tired, sick of looking at the code, and just ready to be done with it. I stage the changes as I go (particularly the small changes) and leave the meaty changes for last to be analyzed carefully against the original source.
- belovedeagle 10y ago
  > I would like my team to be prevented from ever creating untested commits Frankly, this demonstrates that you have exactly zero understanding of how git works. If I were the sort to force my team to do something, I would force them to never test uncommitted code. Committed /= pushed. A commit means you can keep working on the code while the tests run, and you won't forget what you actually tested. Then, when the tests come back clean, you won't accidentally push some additional, untested change along with the tested changes.
  - prodigal_erik 10y ago
    If you can concurrently build/test and edit, you necessarily have more than one workspace, one of which can take the place of the staging area. I do like the idea of having a snapshot of a test run, though we'd have to amend the commit or something to indicate that it passed its tests and is a sane parent for new commits on its branch, and I would switch to working on an independent feature rather than trying to do work on code which may or may not be broken.
    - belovedeagle 10y ago
      > If you can concurrently build/test and edit, you necessarily have more than one workspace, one of which can take the place of the staging area. This takes a really narrow view of what software projects can be hosted in git. If you're working on a huge project which must be built (at least for full builds) and tested "in the cloud", which you trigger by pushing to a temporary remote branch, then no, you need not have more than one workspace. If you're a webdev, then yeah, gitless or any other git workflow without the staging area might be useful for you.
      - prodigal_erik 10y ago
        I'm sure that workflow can be made to work, but if I had to answer the question "assume you can't test on your editing box nor edit on your testing box, so how do you get source from your editing box to your testing box?" git would not be anywhere near the top of my list of solutions because it leaves known-bad commits pushed that need to be contained like waste.
derefr 10y ago
> Also, if you end up committing only parts of files, then how do you know that what you commit works? Because one part was, say, whitespace-errors corrected by my editor, or added/updated comments, or removed dead-and-commented code paths, while the other part was an actual logic change. There are many reasons to modify a file of source-code beyond making the code behave differently, but frequently those aspects come together as "oh, I'll just fix this while it's staring me in the face" and must be picked back apart later.
Mithaldu 10y ago
I do this all the time and the answer is: I test it. If there's a certain set of changes i wish to commit in one unit, but i have other changes in flight, then i use staging to prepare and reason about them while being able to diff both staging<->previous and staging<->hdd, make the commit, then stash the hdd state and run tests. Afterwards i can restore the hdd from stash and either amend the commit if necessary, or keep on working.
alphapapa 10y ago
> Also, if you end up committing only parts of files, then how do you know that what you commit works? You use your knowledge as a programmer to determine what that part of the file does and whether it can stand independently as a change. This is not always obvious, so in that case, you don't do it. But when it is obvious, it makes it quick and easy to commit it separately. For example, say you rewrote a function in a script, and while you were at it you improved the usage info (--help). Then you go to commit your changes. You look at each changed hunk, and you see that there are two changed hunks: the function you changed and the help message. With Magit, it's dead simple to commit them separately: 1) select the first hunk, 2) s to stage, 3) c to commit, 4) write the commit message and execute the commit, 5) select the second hunk... And let's say that, while you were rewriting the function, you commented out some code in the old function. You obviously don't want to keep that old code in the new function, so when you are looking through the changed hunks, you select those lines and press k to revert (or kill) those lines containing the commented code. If you have already staged them, then you can simply select those lines and press u to unstage just those lines, removing them from the staging area but preserving them in the working tree. The workflow of 1) develop, 2) review and stage related hunks, 3) commit staged hunks, 4) goto 2, also helps a lot by forcing the developer to look at the code he's about to commit. Of course you can just stage everything that's changed and make a big commit, but I find that using the staging area to build up commits before making them helps me catch things that I don't want to commit in the first place. It's really useful for managing config files, because you can commit only the parts you want to save or sync to other systems, while leaving some parts active in the working tree but out of the committed branch. For example, the Picard music tagger stores window and dialog positions in the same config file along with behavioral settings. I want to store and sync changes to the options, but I don't want to commit and sync every time the window position changes. The staging area is a powerful (yet essentially optional) feature that, when used correctly, gives the developer great power to make commits more logically independent, while allowing him to develop freely, with little concern for how he will eventually commit the changes he's making.
- acemarke 10y ago
  Thank you. Exactly the kind of workflow I was trying to describe, but said better.
to3m 10y ago
Well, you don't, so... don't do that. Same thing goes for Perforce; you can already create multiple changelists that you commit independently, so it's easy enough to create a bad commit, because it contains only some of the changes you've got locally. What you're supposed to do in Perforce of course is to create your changelist, shelves the others, make sure your proposed changelist works independently, and commit it only when it does. Which is analogous to what you're supposed to do with git: - stage parts of files - `git stash -k' - check it works - `git stash pop' - commit But let's be serious here - the true advantage of git comes when you do the pro move. - stage parts of files - commit - (90% of the time) it's good - (10% of the time) bzzt... it's bad Now, if you were using Perforce, in the 10% case, you'd be stuffed. Somebody would come over to your desk. - (them) "Your commit is broken" Now what can you do? There's no denying it... you gone done fucked up, and there's no denying it. But with git, you have options. So let's try that again. - (them) "Your commit is broken" - (you) (confident tone of voice) "Ah no, you are using git incorrectly, you forgot to git fetchpack --inflate-upstream-probability-leaves --deny-downstream-packs --integrate-sideway-arguments --discombobulate-flat-file-compressed-alignment-jobs -P -Q -J 5 -N 311 -X 0771 -R 0x134774" - (them) (uncertain) - (you) (confident gaze. Straight into their eyes. YOU = TIGER) - (them) (increasingly uncertain) - (you) (unblinking gaze. You have the upper hand. YOU = 2 TIGERS) - (them) (wanders off to try your technobabble) - (you) (fixes your commit) There's an xkcd about this. The advantages, I think, are clear.
- rakpol 10y ago
  Aah, sweet, someone else who uses Perforce! I've been wondering, do you use version control as: 1. a way to record logical changes to files (e.g. implement two features without making any commits, then when you're done, pick out the files/chunks that encode each feature and create commits out of them), 2. a record of history (e.g. just start writing code and make a commit every time you compile/run tests without unexpected failures), 3. something else? I've found it very painful to apply my git-adapted workflow to Perforce: I _want_ to just start coding, testing out various possible design choices and implementations instead of only theorizing about them, but can't (e.g. "I wonder if I could factor out these methods + fields into a different class?" Perforce: oh well, I guess I should write it down somewhere to remember for later. Git: branch my current work, spend five minutes sketching an extraction, then realize it's insane and continue working). Am I crazy and just don't realize ow much better the Perforce model is?

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).
  - slavik81 10y ago
    I worked for many years with version systems that didn't include staging. People still frequently forgot to commit necessary files. Opinions may differ, but I feel the best place to enforce that constraint is with a CI server that merges only working changes.
    - prodigal_erik 10y ago
      This is a symptom of offering an option to perform an incomplete commit. Word processors don't have this problem because they don't make you specify which paragraphs are important enough to save. I commit the workspace. If I'm not happy with some of the workspace, I fix it (or stash it for later when chaos happens).
  - parenthephobia 10y ago
    If you're trying to enforce tested commits without running tests on what's actually committed, you're doing it wrong. There's an inherent incompatibility between the supposed ways that the staging area can be replaced with other things. If you replace it with a commit you keep amending as you go, but also all commits must pass tests, then you can never commit partially complete code, which defeats the purpose of having the amending commit. If you interactively choose what to commit at commit time, then you run the risk of failing the test and then, after fixing whatever was wrong, having to remember which parts of which files it was you chose to commit last time. Now, you could choose to have your CVS remember that for you, but then you're basically reinventing a less-capable version of the staging area. If you simply commit everything, then you can never have any code in your working tree which breaks tests, nor can you have code which isn't logically part of the commit you're currently working on. In practice that means that when you find things that need fixing that aren't directly related to what you're doing, you either fix it and commit it with unrelated changes - which interacts poorly with merging or reverting those commits - or you don't fix it and, most probably, forget about it.
  - kcburge 10y ago
    The staging area is extremely helpful, beyond just making a single selective/partial commit. Other uses: 1. Breaking a large commit into multiple smaller commits. 2. As a simple "review" system. You stage files that have been reviewed so you know you don't have to look at them again, while continuing on a change. 3. Cleaning the working copy of superfluous changes/files. If you stage the files you want to keep, then clean and/or checkout force, it wipes out the files you didn't stage. Then just reset to unstage all files and continue making changes. 4. Splitting a branch into two different branches, when you realize that a branch could be broken down into smaller separate changes that are both incomplete, but COULD be committed separately. You merge squash to master, staging and commit creating a new branch for feature1, then stage, stash, and stash pop the rest back on to master (since sometimes you cannot just switch back to master), and create the feature2, and feature3 branches, etc. I also use Magit in Emacs, which makes the staging area like the swiss army knife of Git. I cannot image the amount of extra pointless tedious work that would be required using commits, branches, and merges to simulate the equivalent behavior of the staging area. The staging area is used heavily by folks who like to get a lot of things done with minimal effort required. I understand the difficulty for new users switching to Git, and I agree that the commands could be more clear and consistent, but beginner (commit all) and novice (selective commit) users should not be left to determine the utility of Git features they very likely do not fully understand or appreciate.
    - e12e 10y ago
      > 2. As a simple "review" system. You stage files that have been reviewed so you know you don't have to look at them again, while continuing on a change. (How) does this work if you want/need a virtual paper trail of reviews and/or in a distributed team? Do you email your changes for review, without making a commit and push (to a branch and/or fork)? Apologies if I misunderstand what you mean, but I read "review" here as colleague walks by and have a look, and says lgtm?
      - kcburge 10y ago
        This is personal review, not peer review. I try to review my code after completion and a period of rest before submitting for peer review. This discipline finds a surprising number of issues with my code that I just didn't see when I was tired, sick of looking at the code, and just ready to be done with it. I stage the changes as I go (particularly the small changes) and leave the meaty changes for last to be analyzed carefully against the original source.
belovedeagle 10y ago
> I would like my team to be prevented from ever creating untested commits Frankly, this demonstrates that you have exactly zero understanding of how git works. If I were the sort to force my team to do something, I would force them to never test uncommitted code. Committed /= pushed. A commit means you can keep working on the code while the tests run, and you won't forget what you actually tested. Then, when the tests come back clean, you won't accidentally push some additional, untested change along with the tested changes.
- prodigal_erik 10y ago
  If you can concurrently build/test and edit, you necessarily have more than one workspace, one of which can take the place of the staging area. I do like the idea of having a snapshot of a test run, though we'd have to amend the commit or something to indicate that it passed its tests and is a sane parent for new commits on its branch, and I would switch to working on an independent feature rather than trying to do work on code which may or may not be broken.
  - belovedeagle 10y ago
    > If you can concurrently build/test and edit, you necessarily have more than one workspace, one of which can take the place of the staging area. This takes a really narrow view of what software projects can be hosted in git. If you're working on a huge project which must be built (at least for full builds) and tested "in the cloud", which you trigger by pushing to a temporary remote branch, then no, you need not have more than one workspace. If you're a webdev, then yeah, gitless or any other git workflow without the staging area might be useful for you.
    - prodigal_erik 10y ago
      I'm sure that workflow can be made to work, but if I had to answer the question "assume you can't test on your editing box nor edit on your testing box, so how do you get source from your editing box to your testing box?" git would not be anywhere near the top of my list of solutions because it leaves known-bad commits pushed that need to be contained like waste.

derefr 10y ago

> Also, if you end up committing only parts of files, then how do you know that what you commit works? Because one part was, say, whitespace-errors corrected by my editor, or added/updated comments, or removed dead-and-commented code paths, while the other part was an actual logic change. There are many reasons to modify a file of source-code beyond making the code behave differently, but frequently those aspects come together as "oh, I'll just fix this while it's staring me in the face" and must be picked back apart later.

Mithaldu 10y ago

I do this all the time and the answer is: I test it. If there's a certain set of changes i wish to commit in one unit, but i have other changes in flight, then i use staging to prepare and reason about them while being able to diff both staging<->previous and staging<->hdd, make the commit, then stash the hdd state and run tests. Afterwards i can restore the hdd from stash and either amend the commit if necessary, or keep on working.

alphapapa 10y ago

> Also, if you end up committing only parts of files, then how do you know that what you commit works? You use your knowledge as a programmer to determine what that part of the file does and whether it can stand independently as a change. This is not always obvious, so in that case, you don't do it. But when it is obvious, it makes it quick and easy to commit it separately. For example, say you rewrote a function in a script, and while you were at it you improved the usage info (--help). Then you go to commit your changes. You look at each changed hunk, and you see that there are two changed hunks: the function you changed and the help message. With Magit, it's dead simple to commit them separately: 1) select the first hunk, 2) s to stage, 3) c to commit, 4) write the commit message and execute the commit, 5) select the second hunk... And let's say that, while you were rewriting the function, you commented out some code in the old function. You obviously don't want to keep that old code in the new function, so when you are looking through the changed hunks, you select those lines and press k to revert (or kill) those lines containing the commented code. If you have already staged them, then you can simply select those lines and press u to unstage just those lines, removing them from the staging area but preserving them in the working tree. The workflow of 1) develop, 2) review and stage related hunks, 3) commit staged hunks, 4) goto 2, also helps a lot by forcing the developer to look at the code he's about to commit. Of course you can just stage everything that's changed and make a big commit, but I find that using the staging area to build up commits before making them helps me catch things that I don't want to commit in the first place. It's really useful for managing config files, because you can commit only the parts you want to save or sync to other systems, while leaving some parts active in the working tree but out of the committed branch. For example, the Picard music tagger stores window and dialog positions in the same config file along with behavioral settings. I want to store and sync changes to the options, but I don't want to commit and sync every time the window position changes. The staging area is a powerful (yet essentially optional) feature that, when used correctly, gives the developer great power to make commits more logically independent, while allowing him to develop freely, with little concern for how he will eventually commit the changes he's making.

acemarke 10y ago
Thank you. Exactly the kind of workflow I was trying to describe, but said better.

to3m 10y ago

Well, you don't, so... don't do that. Same thing goes for Perforce; you can already create multiple changelists that you commit independently, so it's easy enough to create a bad commit, because it contains only some of the changes you've got locally. What you're supposed to do in Perforce of course is to create your changelist, shelves the others, make sure your proposed changelist works independently, and commit it only when it does. Which is analogous to what you're supposed to do with git: - stage parts of files - `git stash -k' - check it works - `git stash pop' - commit But let's be serious here - the true advantage of git comes when you do the pro move. - stage parts of files - commit - (90% of the time) it's good - (10% of the time) bzzt... it's bad Now, if you were using Perforce, in the 10% case, you'd be stuffed. Somebody would come over to your desk. - (them) "Your commit is broken" Now what can you do? There's no denying it... you gone done fucked up, and there's no denying it. But with git, you have options. So let's try that again. - (them) "Your commit is broken" - (you) (confident tone of voice) "Ah no, you are using git incorrectly, you forgot to git fetchpack --inflate-upstream-probability-leaves --deny-downstream-packs --integrate-sideway-arguments --discombobulate-flat-file-compressed-alignment-jobs -P -Q -J 5 -N 311 -X 0771 -R 0x134774" - (them) (uncertain) - (you) (confident gaze. Straight into their eyes. YOU = TIGER) - (them) (increasingly uncertain) - (you) (unblinking gaze. You have the upper hand. YOU = 2 TIGERS) - (them) (wanders off to try your technobabble) - (you) (fixes your commit) There's an xkcd about this. The advantages, I think, are clear.

rakpol 10y ago
Aah, sweet, someone else who uses Perforce! I've been wondering, do you use version control as: 1. a way to record logical changes to files (e.g. implement two features without making any commits, then when you're done, pick out the files/chunks that encode each feature and create commits out of them), 2. a record of history (e.g. just start writing code and make a commit every time you compile/run tests without unexpected failures), 3. something else? I've found it very painful to apply my git-adapted workflow to Perforce: I _want_ to just start coding, testing out various possible design choices and implementations instead of only theorizing about them, but can't (e.g. "I wonder if I could factor out these methods + fields into a different class?" Perforce: oh well, I guess I should write it down somewhere to remember for later. Git: branch my current work, spend five minutes sketching an extraction, then realize it's insane and continue working). Am I crazy and just don't realize ow much better the Perforce model is?