Björn Steinbrink <B.Steinbrink@xxxxxx> writes: > On 2010.04.22 22:37:05 +0200, Goswin von Brederlow wrote: >> Is there a risk? You do get an editor with all the files affected listed >> giving you a big fat warning what you are about to commit. > > And if I happen to have two unrelated changes in a single file that's > worth nothing at all. For example, I might have changed the condition > that causes some message to be shown, and discovered a typo in the > message itself and fixed it along the way. That needs two commits, but > the list of modified files doesn't tell that. > > Only "commit -v" would help there, showing the diff in the editor. But > reviewing the diff in the editor is a PITA and I lose the whole review > progress if I find something I don't want to commit and have to abort. > Using "git add [-i|-p|-e]", git helps me to keep track of the changes I > already reviewed and decided to commit. And how do you check your changes for correctness before committing? I have a habit to only commit the exact tree I've compiled, and I can compile only the working tree, not the index, right? So for me, committing the index sounds to be a wrong idea (unless it matches the work-tree). I think I'd like to have an ability to temporarily undo some of changes putting them on shelf for later re-application (sounds like extension to stash?). This way, when preparing perfect commit, I'd undo everything unrelated, check (build/run) the result, then commit. Then I'd re-do everything that was undone using single command that would take all the changes from the shelf back to working tree. Repeat as appropriate. Multiple shelves would be the next improvement that will allow to immediately sort the changes into different changesets during undoing. Just dreaming... At least that's roughly how I actually managed this with CVS using patch and emacs, -- far from being pretty, but works. -- Sergei. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html