Timeline for What is the benefit of git's two-stage commit process (staging)?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 1, 2020 at 21:09 | comment | added | cja | Both of these use cases are handled in Mercurial without the staging concept. Have read about ten attempts to explain the point of staging so far and all fail because the authors seem ignorant of the capabilities of other VCSs, as in this case. | |
| Oct 16, 2018 at 22:45 | comment | added | Mark Amery |
-1 because the staging area doesn't actually have anything to do with the first point here. @alpha_989's question is bang on: allowing the user to commit only some of their working directory's changes at once doesn't require two-stage commit, as evidenced by Mercurial, which has one-stage commit but still offers hg commit --interactive.
|
|
| Apr 10, 2018 at 17:24 | comment | added | alpha_989 |
@thomasrutter, From your statement, it seems you are suggesting that the staging area creates "manual undo points". In VIM with persistent-undo, you can get unlimited history very reliably. This is also tracked automatically in a git-branch type fashion (jovicailic.org/2017/04/vim-persistent-undo). Further your undo history is automatically tracked everytime you go into normal mode. So it reduces your mental burden of having to create "manual undo points". Why is using your editors "undo" buffers not as methodical?
|
|
| Apr 10, 2018 at 17:18 | comment | added | alpha_989 |
Your first point makes sense, though I haven't used it, so far. Theoretically why can't you do something like a git add -i with a single stage commit? You would just pick a bunch of files (or lines within files) related to a single feature, and do a commit. Then you would come back and do a second commit related to another feature..
|
|
| Apr 10, 2018 at 17:15 | comment | added | alpha_989 | @l0b0, about your second point. If there was just a single stage commit, you could have just committed the changes (that you use with git add) directly as a commit. If you found out that you did something wrong, you would have just deleted the commit, and got back to where you were before you made the commit. With the staging concept, aren't you just doing that, but adding more complexity? | |
| S Mar 17, 2017 at 16:51 | history | suggested | Jeromy French | CC BY-SA 3.0 |
Defining RCS by enumerating acronym and linking to further detail
|
| Mar 17, 2017 at 15:04 | review | Suggested edits | |||
| S Mar 17, 2017 at 16:51 | |||||
| Oct 12, 2014 at 17:04 | comment | added | Lucio Paiva | Regarding "other RCSes", that is not necessarily true. In fact, you can achieve those same functionalities in Mercurial using patches. | |
| Apr 19, 2011 at 6:23 | vote | accept | thomasrutter | ||
| Apr 19, 2011 at 6:21 | comment | added | thomasrutter | Coming from a DVCS (bzr) that does not have this feature, that sounds a lot like what I currently achieve with a combination of liberal use of my editor's "undo" buffers, the "revert <file>" command and selective commits ("commit <file>"). Sounds like this feature of git has the potential to be more methodical. | |
| Apr 18, 2011 at 9:47 | history | edited | l0b0 | CC BY-SA 3.0 |
Another example; added 10 characters in body
|
| Apr 18, 2011 at 9:38 | history | answered | l0b0 | CC BY-SA 3.0 |