On Wed, 14 Nov 2012 07:10:20 -0800 (PST) John McKown <john.archie.mck...@gmail.com> wrote:
> This just occurred to me. I am running on Linux. I use "make" to do > my compiles. Which I do in the working directory. I don't want the > results of the compiles to be tracked in git. What I have done in the > past is to have a clean directory when I did the "git commit", often > with a "make clean" command. Also I have tried to put the generated > file names into my .gitignore file. But what has occurred to me is to > use branching. Maintain my source while I am in the "master" branch. > Just before I do a "make", do "git checkout -b test" to switch to the > "test" branch, creating it if necessary. Once I am finished testing, > I do a "git checkout master" and git will "clean up" my working > directory for me. I would never do a "git commit" while in the "test" > branch. And I would periodically do a "git branch -D test" to totally > clean up the "test" branch. Is this reasonable? Or just plain foolish? It's clearly an overengeneering. The .gitignore file and other ways of ignoring stuff were primarily invented to make Git not be interested in auto-generated cruft. So just have your auto-generated cruft sitting in your work tree and forget about it. The only problem it might create is occasional adding of unwanted files to the index and committing. But this problem is really social: *always* run `git status` before committing and check to see if you have any odd files in the output. --
