3 ms·

I disagree. Forcing a weird pseudo commit, with its own unique set of commands for interacting with it, into the basic workflow is not the right approach. Wit

by krupan 10y ago

I disagree. Forcing a weird pseudo commit, with its own unique set of commands for interacting with it, into the basic workflow is not the right approach. Without an index, beginners can just commit. As people get more adventurous, they can learn commands like commit --amend and rebase --interactive to build up and massage their commits.

spinningarrow 10y ago
So what would be the workflow for committing (and perhaps pushing) partial changes in that case? Say you've made a lot of changes and they don't all belong together.
- gkya 10y ago
  If I needed to do a partial commit I'd record the diff ("git diff > big.patch" or git stash), clean the repository, and build the patch to be committed manually picking from the recorded diff, test thoroughly and commit only when the patch is coherent (ie tests pass, compiles and runs). Then I'd just apply the rest of the patch to continue working. AFAIK the git model (git add [-p]) and history editing makes it very easy and probable to produce incoherent commits which when checked out does not compile, test all-OK or behave wrong. I use CVS for my personal stuff for various reasons but even if I used git I'd do it like this. P.S. if your granularity is in the level if files and not individual hunks of the overall patch then you can just "cvs/git commit files..." easily but still, it'll go in untested and you may have forgotten a change that was required in order to make the commited patch valid and coherent.
  - rtb 10y ago
    I used to do that with SVN. What a pain in the ass. Git's version is miles better.
  - bicolao 10y ago
    Do partial commits. Run a new interactive rebase session, set "edit" to all those commits so you can test out individual ones and fix up some more if needed. Basically the same outcome, but less manual diff editing.

3 ms·

I disagree. Forcing a weird pseudo commit, with its own unique set of commands for interacting with it, into the basic workflow is not the right approach. Wit

by krupan 10y ago

spinningarrow 10y ago
So what would be the workflow for committing (and perhaps pushing) partial changes in that case? Say you've made a lot of changes and they don't all belong together.
- gkya 10y ago
  If I needed to do a partial commit I'd record the diff ("git diff > big.patch" or git stash), clean the repository, and build the patch to be committed manually picking from the recorded diff, test thoroughly and commit only when the patch is coherent (ie tests pass, compiles and runs). Then I'd just apply the rest of the patch to continue working. AFAIK the git model (git add [-p]) and history editing makes it very easy and probable to produce incoherent commits which when checked out does not compile, test all-OK or behave wrong. I use CVS for my personal stuff for various reasons but even if I used git I'd do it like this. P.S. if your granularity is in the level if files and not individual hunks of the overall patch then you can just "cvs/git commit files..." easily but still, it'll go in untested and you may have forgotten a change that was required in order to make the commited patch valid and coherent.
  - rtb 10y ago
    I used to do that with SVN. What a pain in the ass. Git's version is miles better.
  - bicolao 10y ago
    Do partial commits. Run a new interactive rebase session, set "edit" to all those commits so you can test out individual ones and fix up some more if needed. Basically the same outcome, but less manual diff editing.