4 ms·

I don't doubt that not having the staging area would make it better for new users, as it is certainly conceptually simpler to just commit everything. And for t

I don't doubt that not having the staging area would make it better for new users, as it is certainly conceptually simpler to just commit everything. And for those who's revision control model is always linear commits of what's in the working copy, it really is just added work and complexity. But it enables other workflows (that I personally happen to use a lot) that are easy with staging and /very/ inconvenient without. So yeah, feel free to leave it out of your implementation; it doesn't seem like something that'd fit into the plan9 mindset anyway. But it is removing a very useful tool to some people.

jdsully 8y ago
Could you elaborate on this workflow? I'm trying hard to think of one and not coming up with anything.
- black-tea 8y ago
  I often make many changes at once and then begin to commit pieces of it incrementally as I go. Each commit should represent a perfectly valid version of the code base, but your working directory rarely represents a valid version during development. Without the staging area I wouldn't be able to begin commiting, and therefore using git, until much later, maybe days later.
  - kstenerud 8y ago
    I follow a similar workflow: 1. Make exploratory modifications 2. "git add" pieces that I think are "commit worthy", even if I'm not sure I want to actually commit it yet (still exploratory work). 3. If I decide I don't like the latest set of modifications, I clear them all, going back to what's in my pseudo-commit. 4. Once I'm happy with it as a whole, I turn it into a real commit, complete with message. What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. If pseudo-commit stacks had first class treatment, you could even stash them, which would be great if some other emergency came along that you had to deal with now. Internally, you could create some kind of HEAD-like pointer for this, store commits that go from HEAD to PSEUDOHEAD, and then when you're finally ready to commit, squashes everything from HEAD to PSUEDOHEAD and follows standard commit procedure from there. Or maybe you could implement it as a "reset HEAD" kind of thing to collapse the pseudo-commits, which then allows you to use standard partial commit semantics if needed. Actually, now that I think of it, I could do a poor man's version by tagging REALHEAD before I start, making actual, real commits as I go, and then "git reset REALHEAD" to start building the actual commit I want...
    - black-tea 8y ago
      Doesn't git reset do what you want? For example git reset <remote>/<branchname> would usually do it for me, but you could just as easily do it to any other commit.
    - brmgb 8y ago
      > What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. Mercurial patch queue is pretty much that. You can also use temporary commit and phases to ensure they are not visible from outside your local repository. I have never really understood why git introduces all this weird concepts (staging, stash) for what are just temporary commits in the end.
    - klyrs 8y ago
      > What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. I use branches for this, and private remote repos. I thought that stash was magical and cool until that time I stashed in the middle of a merge and dug into the details of stash... If I hate the state of my experimental branch, I kill it. If I want to keep parts, I cherry-pick them over to another experimental branch. When I want to keep fractions of patches, I manually copy deltas across with git-difftool (which was the only real reason I was stashing anyway). And when I finally have a branch that I'm happy with keeping, then I use "git merge -i" to collect the mini-commits into a sensible history
  - skellera 8y ago
    If you are committing subsets of your work, how can you guarantee than each commit is a working version of the code? Some committed code being dependent on uncommitted code. Or am I missing something?
    - black-tea 8y ago
      I don't know... I just know. Is it that hard? I'm always pushing to remote and triggering CI and I rarely break the build.
- didibus 8y ago
  I use it a lot. Sometimes, you want to have a temporary snapshot, but not a commit. So I write some code, it works, but I'm thinking of trying some things out. I stage the working code and make more diffs. Now I can have my editor show the diffs between my stage and my new changes. And I can easily rollback individual files or re-stage some more files. Until I am satisfied. And now decide to make a commit. I could just make them all commits, and then do a interactive rebase as well. And I do that too. But sometimes the staging area is just simpler and quicker. With git status I can see it at a glance. Etc.
- Izkata 8y ago
  My main use is keeping debug statements (print, pdb) separate from things I want to commit. Like the others, this is daily use for me.

jdsully 8y ago

Could you elaborate on this workflow? I'm trying hard to think of one and not coming up with anything.

black-tea 8y ago
I often make many changes at once and then begin to commit pieces of it incrementally as I go. Each commit should represent a perfectly valid version of the code base, but your working directory rarely represents a valid version during development. Without the staging area I wouldn't be able to begin commiting, and therefore using git, until much later, maybe days later.
- kstenerud 8y ago
  I follow a similar workflow: 1. Make exploratory modifications 2. "git add" pieces that I think are "commit worthy", even if I'm not sure I want to actually commit it yet (still exploratory work). 3. If I decide I don't like the latest set of modifications, I clear them all, going back to what's in my pseudo-commit. 4. Once I'm happy with it as a whole, I turn it into a real commit, complete with message. What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. If pseudo-commit stacks had first class treatment, you could even stash them, which would be great if some other emergency came along that you had to deal with now. Internally, you could create some kind of HEAD-like pointer for this, store commits that go from HEAD to PSEUDOHEAD, and then when you're finally ready to commit, squashes everything from HEAD to PSUEDOHEAD and follows standard commit procedure from there. Or maybe you could implement it as a "reset HEAD" kind of thing to collapse the pseudo-commits, which then allows you to use standard partial commit semantics if needed. Actually, now that I think of it, I could do a poor man's version by tagging REALHEAD before I start, making actual, real commits as I go, and then "git reset REALHEAD" to start building the actual commit I want...
  - black-tea 8y ago
    Doesn't git reset do what you want? For example git reset <remote>/<branchname> would usually do it for me, but you could just as easily do it to any other commit.
  - brmgb 8y ago
    > What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. Mercurial patch queue is pretty much that. You can also use temporary commit and phases to ensure they are not visible from outside your local repository. I have never really understood why git introduces all this weird concepts (staging, stash) for what are just temporary commits in the end.
  - klyrs 8y ago
    > What would be really nice is some sort of "pseudo-commit stack" whereby you can do this workflow, but every mini-commit goes into a stack that you can unwind to whatever point you want if it turns out that you've been going down a blind alley. I use branches for this, and private remote repos. I thought that stash was magical and cool until that time I stashed in the middle of a merge and dug into the details of stash... If I hate the state of my experimental branch, I kill it. If I want to keep parts, I cherry-pick them over to another experimental branch. When I want to keep fractions of patches, I manually copy deltas across with git-difftool (which was the only real reason I was stashing anyway). And when I finally have a branch that I'm happy with keeping, then I use "git merge -i" to collect the mini-commits into a sensible history
- skellera 8y ago
  If you are committing subsets of your work, how can you guarantee than each commit is a working version of the code? Some committed code being dependent on uncommitted code. Or am I missing something?
  - black-tea 8y ago
    I don't know... I just know. Is it that hard? I'm always pushing to remote and triggering CI and I rarely break the build.
didibus 8y ago
I use it a lot. Sometimes, you want to have a temporary snapshot, but not a commit. So I write some code, it works, but I'm thinking of trying some things out. I stage the working code and make more diffs. Now I can have my editor show the diffs between my stage and my new changes. And I can easily rollback individual files or re-stage some more files. Until I am satisfied. And now decide to make a commit. I could just make them all commits, and then do a interactive rebase as well. And I do that too. But sometimes the staging area is just simpler and quicker. With git status I can see it at a glance. Etc.
Izkata 8y ago
My main use is keeping debug statements (print, pdb) separate from things I want to commit. Like the others, this is daily use for me.