Thanks Jan, Jason, Jonathan, and Thomas for your response, your thoughts and concerns are enlightening.... Jan Kruger wrote... > git config --global alias.commitx '!git add . && git commit' > git config --global alias.checkoutx '!git clean && git checkout' Thank you. Being new to git, I did not know that such aliasing was available within it. Jason Sewell wrote... > If you have a bunch of debugging code sitting around in your working tree after you've tracked down a > problem, you don't want to commit all of those printfs, etc. - you want to commit the fix. This has > ramifications from making diffs of history cleaner to making git bisect actually useful. One of the concerns I have with the manual pick-n-commit is that you can forget a file or two. Consequently, unless you do a clean checkout and test of the commit, you don't know that your publishable version even compiles. It seems safer to commit the entirety of your work in its working state and then do a clean checkout from a dedicated publishable branch and manually merge the changes in that, test, and commit. It seems the intuitive model is to treat version control as applying to the whole document, not parts of it. In this respect the document is defined by the IDE, namely the entire solution, warts and all. When you start selectively saving parts of the document then you are doing two things, versioning and publishing; and at the same time. This was a critical flaw in older version control approaches because the software solution document is a file system sub-tree. What you termed the debugging/printf's I would treat as a distinctions between a debug vs. a release version that may be suitably delineated by #define's or preferably separate unit tests assemblies. If I must prune prior to committing; however, then it seems reverting spurious printf's may offer a more reliable and automatable technique than ensuring that I have added all the new class files, resource files, text files, sub projects, etc; that may constitute the "fix." Once so selectively reverted I can test and commit such a publishable version. Jason Sewell wrote... > Isn't fastidiously maintaining a .gitignore file to contain everything you *don't* want in the project more confusing > than explicitly specifying things you *do* want in the project? This is git ignore for "cleaning prior to a check" and git ignore for "adding to index" and is not an either or. You would specify what you don't want to version tracked as normal but you can also stipulate what you don't want to be deleted during a clean restore (which should otherwise completely wipe the folder prior to restoring a specific commit). This would permit embedding non-version elements within the version tree for whatever reason you find necessary. Thomas Rast wrote... > That would require supernaturally good maintenance of your .gitignore to avoid adding or (worse) nuking files by accident. On the contrary, the approach would all but eliminate the possibility of loss of data since you would not manually (and therefore error prone-ingly) pruning until after a commit. In fact, one might default automatic commits (if required) prior to checkouts or at least an alert system when uncommitted changes exists. Thanks again for your input. -- 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