You can always create or add them to a .gitignore file. If at the top-
level GIT repo, this file impacts the whole repo. You would literally
add "*.o" (but without the ""s) to this file to ignore all *.o files.
Just be careful to not ignore port-original files.
Example of how I do it; slightly different than Mojca's:
{{{
sudo port extract gr-ofdm
pushd $(port work gr-ofdm)
sudo chmod -R a+rw .
cd gr-ofdm<tab>
git init
git add -A
git commit "init" > /dev/null
}}}Then, go about editing & any change will easily be found via "git status". You can also revert back to the "init" (or last commit) version of a file via "git checkout -- [filename]". Getting the changes is easy, via "git diff" ... but note that this diff is "patch -p1" style, not the usual MacPorts "patch -p0" style. It's easy to convert between them, but will generally be a pain if a lot of files have been changed. My git-foo isn't very strong, but these I know & they work quite well for fixing MacPorts ports via source. Using the above, to get back to the directory where you were, just do "popd". Another benefit to the "chmod" at the top-level "work" directory is that you can then edit the ".macports.*.state" file -- e.g., to revert the state back to "patched" so-as to force configuration again. Or you can remove the build or destroot directory without having to "sudo"; ditto for file editing. Hope this helps! - MLD On Wed, Aug 30, 2017, at 12:50 PM, Ken Cunningham wrote: > > On 2017-08-30, at 9:41 AM, Michael Dickens wrote: > >> What Mojca wrote is what I do too. Simple but very effective! - MLD >> > > Is there a way to make git ignore the *.o and *.a and other generated > files that might be in the source tree that we're not interested in > tracking -- or does the -A do that automatically?
