6 ms·

Curious as to why - What usecases do you have for staging? Why does sourcetree make it better? To me it's just an inconvenience and a redundant step on the way

Curious as to why - What usecases do you have for staging? Why does sourcetree make it better? To me it's just an inconvenience and a redundant step on the way to committing stuff. I get that you can use it for partial commits of in flight work but that's never something I've needed in practice. Usually I just want to commit everything I'm working on at once.

vthriller 8y ago
I split file changes into multiple commits all the time. That alone makes many diffs much more readable and changes easier to follow, even if it results in occasional git-log clutter.
jayd16 8y ago
You might not use it to do partial commits but many others do.
- joppy 8y ago
  Don't partial commits run the big risk of commiting code that may not work, since the partial commit on your own computer will be tested against your working tree, wheras after it's committed it run with a different view of the files?
  - BalinKing 8y ago
    Just to play devil's advocate, to achieve this always-working guarantee you could: stage, commit, stash your working directory, test your code, and then unstash.
  - jayd16 8y ago
    In reality I use it to do partial stashes more often than partial commits. That said, you could extend your argument such that you should always commit every touched file but that would be awful.
  - explainplease 8y ago
    Not if you know what you're doing. For example, say you added a bunch of TODOs and FIXMEs you noticed in existing code while working on something. Now, you're ready to commit. The TODOs and FIXMEs don't necessarily correlate to the code changes you made. Should they all be committed with the code? Using the index to stage and commit hunks separately lets you easily add and commit the unrelated TODO and FIXME comments separately from the code. A tool like Magit makes it trivially easy to do. And since they're comments, they have no effect on tests or the code.
  - Piskvorrr 8y ago
    It could. OTOH, most workflows I've seen use the approach "do whatever you wish in your repo and in your branches, but merging requires that the tests pass on a CI server, which only has access to the repository and has exactly zero uncommited files. In other words, go ahead and break your builds six ways from Sunday, but they won't get merged until they pass based solely on the state of the repo.
  - kurtisc 8y ago
    Most of the time I'm doing partial commits it's because of squashing them into older commits via rebasing. Rebasing allows you to run an arbitrary command (e.g. your test suite) after each step and will pause the rebase if it returns non-zero.
randallsquared 8y ago
It is common for me to have miscellaneous changes I don’t want to commit, but I think this is problematic on my part, and I shouldn’t typically be doing it. The only defensible version of this I can think of offhand is changes that are necessary to get the repo to work in my local, but which I am not yet able or willing to commit and push.
- saagarjha 8y ago
  You can always use the stash for changes like this.
  - randallsquared 8y ago
    It depends. If you have, as we do at my work, a pre-commit hook that runs acceptance tests on each commit, and if the changes you've made are to get it to work on your local, then leaving those changes in for the test run is really the only option. Should I get those changes committed? I should. But that involves a lot more testing and thought, since it still has to work for other people with different local dev setups.
acemarke 8y ago
Incremental staging of the next commit is absolutely a valuable feature. I'll often touch multiple files over the course of a few hours, sometimes for slightly unrelated changes, and then want to pull apart the changes into several smaller logical commits. Sometimes a couple hunks in a file might need to go into Commit A, while others go into Commit B. You can do piecemeal adding of hunks via the CLI, but the interface is horrible. Being able to simply click "Add Hunk" in a GUI is incredibly valuable (or even in some cases shift-clicking a couple lines and "Add Lines").
- ufo 8y ago
  You can get that kind of interface without a staging area. TortoiseHg would do it using Mercurial's shelving feature (similar to git stash) and IMO that was simpler to understand than staging. In particular, I liked that at all times there was a correspondence between the current working directory and what was being commited. It made it easier to run tests.
  - chousuke 8y ago
    I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. Using stashes would be just reimplementing the index using less convenient UI. I really don't understand what's so difficult about the index... It's just the stuff you will be inserting into the repository when you next commit. Having it separated enables a very convenient workflow that would've required manually using patch and diff when using tools that don't support you. Git is more than just revision storage. I like to think of code as clay, and the index as a tool you use to mould that into the final construct that gets baked
    - Certhas 8y ago
      It makes sense as a tool that should be available. It does not make sense as a default hoop everyone has to jump through. The way that stash, index, working directory and branches interact is completely non-obvious and induces a lot of accidental complexity As far as I can see the use case you describe is actually covered in gl commit.
cyphar 8y ago
What is the redundant step? Do you not use "git commit -a" -- or does it not work in certain cases? Staging is quite useful if you want to create several commits (perhaps fixup commits, perhaps whole commits) based on the current repository state. This is why you can do "git add -p" to add parts of files to staging. You mentioned later in the thread that you prefer stashing -- but Git doesn't let you stash certain files (you have to stash the entire state), and in addition stashing has a much more awful UX than commits (it's represented as a stack which means you have to pop elements off it -- and you've then lost that stack entry and you can't pop the stack with uncommitted changes). If there is one aspect of Git's UX that needs to be massively redesigned it would be "git stash".
maxxxxx 8y ago
Maybe it depends on what you're working on. I often have to try multiple things to see what's working. During that process I slowly stage things that are already working and then move on to the next part. Before the final commit I often discard things that I changed but didn't turn out to be necessary. Maybe there are other ways to do this but for me it's the perfect workflow.

vthriller 8y ago

I split file changes into multiple commits all the time. That alone makes many diffs much more readable and changes easier to follow, even if it results in occasional git-log clutter.

jayd16 8y ago

You might not use it to do partial commits but many others do.

joppy 8y ago
Don't partial commits run the big risk of commiting code that may not work, since the partial commit on your own computer will be tested against your working tree, wheras after it's committed it run with a different view of the files?
- BalinKing 8y ago
  Just to play devil's advocate, to achieve this always-working guarantee you could: stage, commit, stash your working directory, test your code, and then unstash.
- jayd16 8y ago
  In reality I use it to do partial stashes more often than partial commits. That said, you could extend your argument such that you should always commit every touched file but that would be awful.
- explainplease 8y ago
  Not if you know what you're doing. For example, say you added a bunch of TODOs and FIXMEs you noticed in existing code while working on something. Now, you're ready to commit. The TODOs and FIXMEs don't necessarily correlate to the code changes you made. Should they all be committed with the code? Using the index to stage and commit hunks separately lets you easily add and commit the unrelated TODO and FIXME comments separately from the code. A tool like Magit makes it trivially easy to do. And since they're comments, they have no effect on tests or the code.
- Piskvorrr 8y ago
  It could. OTOH, most workflows I've seen use the approach "do whatever you wish in your repo and in your branches, but merging requires that the tests pass on a CI server, which only has access to the repository and has exactly zero uncommited files. In other words, go ahead and break your builds six ways from Sunday, but they won't get merged until they pass based solely on the state of the repo.
- kurtisc 8y ago
  Most of the time I'm doing partial commits it's because of squashing them into older commits via rebasing. Rebasing allows you to run an arbitrary command (e.g. your test suite) after each step and will pause the rebase if it returns non-zero.

randallsquared 8y ago

It is common for me to have miscellaneous changes I don’t want to commit, but I think this is problematic on my part, and I shouldn’t typically be doing it. The only defensible version of this I can think of offhand is changes that are necessary to get the repo to work in my local, but which I am not yet able or willing to commit and push.

saagarjha 8y ago
You can always use the stash for changes like this.
- randallsquared 8y ago
  It depends. If you have, as we do at my work, a pre-commit hook that runs acceptance tests on each commit, and if the changes you've made are to get it to work on your local, then leaving those changes in for the test run is really the only option. Should I get those changes committed? I should. But that involves a lot more testing and thought, since it still has to work for other people with different local dev setups.

acemarke 8y ago

Incremental staging of the next commit is absolutely a valuable feature. I'll often touch multiple files over the course of a few hours, sometimes for slightly unrelated changes, and then want to pull apart the changes into several smaller logical commits. Sometimes a couple hunks in a file might need to go into Commit A, while others go into Commit B. You can do piecemeal adding of hunks via the CLI, but the interface is horrible. Being able to simply click "Add Hunk" in a GUI is incredibly valuable (or even in some cases shift-clicking a couple lines and "Add Lines").

ufo 8y ago
You can get that kind of interface without a staging area. TortoiseHg would do it using Mercurial's shelving feature (similar to git stash) and IMO that was simpler to understand than staging. In particular, I liked that at all times there was a correspondence between the current working directory and what was being commited. It made it easier to run tests.
- chousuke 8y ago
  I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. Using stashes would be just reimplementing the index using less convenient UI. I really don't understand what's so difficult about the index... It's just the stuff you will be inserting into the repository when you next commit. Having it separated enables a very convenient workflow that would've required manually using patch and diff when using tools that don't support you. Git is more than just revision storage. I like to think of code as clay, and the index as a tool you use to mould that into the final construct that gets baked
  - Certhas 8y ago
    It makes sense as a tool that should be available. It does not make sense as a default hoop everyone has to jump through. The way that stash, index, working directory and branches interact is completely non-obvious and induces a lot of accidental complexity As far as I can see the use case you describe is actually covered in gl commit.

cyphar 8y ago

What is the redundant step? Do you not use "git commit -a" -- or does it not work in certain cases? Staging is quite useful if you want to create several commits (perhaps fixup commits, perhaps whole commits) based on the current repository state. This is why you can do "git add -p" to add parts of files to staging. You mentioned later in the thread that you prefer stashing -- but Git doesn't let you stash certain files (you have to stash the entire state), and in addition stashing has a much more awful UX than commits (it's represented as a stack which means you have to pop elements off it -- and you've then lost that stack entry and you can't pop the stack with uncommitted changes). If there is one aspect of Git's UX that needs to be massively redesigned it would be "git stash".

maxxxxx 8y ago

Maybe it depends on what you're working on. I often have to try multiple things to see what's working. During that process I slowly stage things that are already working and then move on to the next part. Before the final commit I often discard things that I changed but didn't turn out to be necessary. Maybe there are other ways to do this but for me it's the perfect workflow.