3 ms·
> you can pick and choose what you want to commit How is that supposed to be a reasonable thing to do? Unlike my working directory, I can't build and test the
by prodigal_erik 17y ago
> you can pick and choose what you want to commit
How is that supposed to be a reasonable thing to do? Unlike my working directory, I can't build and test the contents of the index. To me, making a commit that I've never tested is somewhere between sloppy and negligent, so why is git encouraging me to do it?
- pyre 17y agoI think that your issue is that you're thinking of a commit in git in the same way that you would think of a commit in svn. They are not the same. To commit in svn you are forced to push to the remote repo. Therefore you screw everybody up if your commit hoses things. In git, you can commit locally, and you are not even required to push those changes out. You could trash those commit without anyone ever knowing that you made them. You could make small atomic commits of small changes, and when the feature is ready to be pushed out to the 'canonical' repo, you could squash all of those small commits into one large commit, then push it out.
- prodigal_erik 17y agoAfter some reading, it looks like it's actually possible to use git-checkout-index after an uncommitted merge to get the index contents out where I can test them. I'm still mystified that the preferred workflow is to blindly commit stuff that may not even run, which leaves you with the problem of somehow knowing which of the commits are actually useful points to roll back to or start new work from.