3 ms·

What garbage collection? Isn't staging area actually a feature? I've never used anything else since when I started needing something like 5 years ago git was al

What garbage collection? Isn't staging area actually a feature? I've never used anything else since when I started needing something like 5 years ago git was already a recommended choice, but I also never felt like I needed anything else.

jcranmer 7y ago
If your commits are not referenced by a branch or tag, then those are eventually committed. Having to have a branch to keep the commit around means you need to come up with a name for it if you ever want more than one name. When I go back to Mercurial, it's actually quite relieving to not have to come up with a short name to describe what the current work branch is doing, only commit messages. And no staging area is strictly simpler than having a staging area, which is contrary to your assertion.
- that_jojo 7y ago
  When would you be creating a branch to do work without knowing what work you're doing?
  - jcranmer 7y ago
    It's not that I don't know what work I'm doing, it's that I don't know how to give it a unique name. Sometimes, I try a few different approaches to make something work. Each of these attempts is a different branch--I might need to revisit it, or pull stuff out of it. Good luck staring at a branch name and working out if it's landloop or landloop2 that had the most working version of the code.
    - that_jojo 7y ago
      Super late, but I think a good approach would be to use an issue/work tracker of really any flavor (even manually), log all of your to-do headings as issues, and then just name each branch after the associated issue/job number.
recursive 7y ago
> Isn't staging area actually a feature? I've been using git for a few years, and staging has been all cost with zero benefit so far.
compiler-guy 7y ago
"Isn't staging a feature?" Well yes, but the GP is claiming that git is the most simple thing above file storage. Staging may be a feature, but it adds complexity. Perhaps useful complexity, but complexity nonetheless.

jcranmer 7y ago

If your commits are not referenced by a branch or tag, then those are eventually committed. Having to have a branch to keep the commit around means you need to come up with a name for it if you ever want more than one name. When I go back to Mercurial, it's actually quite relieving to not have to come up with a short name to describe what the current work branch is doing, only commit messages. And no staging area is strictly simpler than having a staging area, which is contrary to your assertion.

that_jojo 7y ago
When would you be creating a branch to do work without knowing what work you're doing?
- jcranmer 7y ago
  It's not that I don't know what work I'm doing, it's that I don't know how to give it a unique name. Sometimes, I try a few different approaches to make something work. Each of these attempts is a different branch--I might need to revisit it, or pull stuff out of it. Good luck staring at a branch name and working out if it's landloop or landloop2 that had the most working version of the code.
  - that_jojo 7y ago
    Super late, but I think a good approach would be to use an issue/work tracker of really any flavor (even manually), log all of your to-do headings as issues, and then just name each branch after the associated issue/job number.

recursive 7y ago

> Isn't staging area actually a feature? I've been using git for a few years, and staging has been all cost with zero benefit so far.

compiler-guy 7y ago

"Isn't staging a feature?" Well yes, but the GP is claiming that git is the most simple thing above file storage. Staging may be a feature, but it adds complexity. Perhaps useful complexity, but complexity nonetheless.