Sorry for the 2x post, George; forgot to include the list in my reply.... On Wed, Nov 18, 2009 at 1:51 PM, George Dennie <gdennie@xxxxxxxxxxxxx> wrote: [some cleanup of quote line wrapping] > Jason Sewall 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. I find git status very useful in preparing a commit; untracked (and 'un-ignored') files are listed right there and I can if there are new source files that are not present but not tracked. You could even add a 'pre-commit hook' to make sure that you don't have any untracked *.c (or whatever) files before you actually make the commit. As to 'publishable' version, it's probably a good idea to run 'make distcheck' or the equivalent before making a release anyway. > 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. I find this leads to big, shapeless commits and, as I mentioned before, it seriously limits the utility of 'git bisect'. I also fail to see how 'selectively saving parts of the document' is versioning and publishing - what is the publishing part? The act of committing is one thing (and 'saving parts of the document' is one conceivable name for it) and publishing another. Your workflow may vary, but before actually 'publishing' (perhaps pushing out to a public repo, or merging into a public branch), it's probably a good idea to test the code with whatever system you use anyway. > 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. What if you are hacking away and make changes to several parts of the code at once? Making the commits as fine-grained as possible makes it easier to cherry-pick, bisect, and understand the history. As to debugging code, I admit I sometimes will use git gui or git add -p to stage just what I want and then put whatever is 'left over' in a branch that I might use again later if another bug comes up. Then I can reset --hard my 'working' branch and the debugging code is gone. > 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. Perhaps I don't understand your scheme, but it sounds like you're advocating 2 .gitignores: * .gitignore_track; with everything you don't automatically staged but which can be trashed by your cleaning checkout * .gitignore_keep; with things you don't want staged but which shouldn't be deleted by git during cleaning That seems even more confusing. I'm actually having trouble seeing why you want this untracked-file nuking checkout at all. Care to give an example? > 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. Who is pruning after a commit? Once nice thing about checkout is that it will refuse to move to a different commit if there are files that will get trashed. Then you can say 'oops, I should stash/commit/nuke that stuff before I change HEAD. Jason -- 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