Overhaul .gitignore structure

[bilderbuchi]

The gitignore structure needs an overhaul. It's become really confusing to read, rules are duplicated (that could be interesting to debug one day:P), and some things don't get ignored properly.
I plan to tackle this some time soon, but will wait for the project manager and whole repo to settle down a bit more. Work will probably happen in https://github.com/bilderbuchi/openFrameworks/tree/gitignore-fixes.

This issue is for the RFC from the core that I'll definitely have when figuring out what you really want/need ignored and what not.

[bilderbuchi]

OK, as a first step I will modify the current setup to make sure all files which are in the repo currently are not being ignored.
I know .gitignore has no effect on already committed files, but if you print all files in the repo which would be ignored otherwise, as in this stackoverflow answer, you can find some (presumed) errors nonetheless.
Script output for interested parties

My questions:

1. Is it really correct that many of the Android example have committed Makefiles and config.make's? Those should be autogenerated and not actually be in the repo, correct? ...kicking those out
2. Theres an xcconfig file in /examples/3d/QuaternionLatLongExample/. That should not be there, right? @obviousjim? ...kicking it out
3. To confirm, libs/openFrameworksCompiled/project/android/paths.make should stay, right? Although, it has some personal paths from @arturoc 's computer in it - what's the deal?
4. There's two pugixml.o files in the project generator. I'm assuming those are in there by mistake, but I'll wait on kicking them out since the pg is still moving around quite much....kicking those out

[obviousjim]

@bilderbuchi yeah the xcconfig should not be there.

[bilderbuchi]

@arturoc , could I have a confirmation either way about paths.make? You explicitly added this to the .gitignore in 8dacae8, but never kicked it out of the repo. Was this an oversight, and should it be deleted? Or should it be in, but then why add it to the ignore list?
(I seem to recall an earlier mention of this in a discussion somewhere, but I couldn't find it)

[arturoc]

paths.make should be there as an example on how to set it up but changes to it should be ignored cause everyone will have a different version in their computers so we don't want it to appear in the unstaged changes. it's kind of weird but it's the only solution i could come up with if.

a

El 28/03/2012, a las 13:54, Christoph Buchner escribió:

@arturoc , could I have a confirmation either way about paths.make? You explicitly added this to the .gitignore in 8dacae8, but never kicked it out of the repo. Was this an oversight, and should it be deleted? Or should it be in, but then why add it to the ignore list?
(I seem to recall an earlier mention of this in a discussion somewhere, but I couldn't find it)

---

Reply to this email directly or view it on GitHub:
#1081 (comment)

[bilderbuchi]

But currently (because it's already tracked) changes to it appear in git status, so I think this solution doesn't actually work at all. E.g. 580d608#diff-1

One way would be to do git update-index --assume-unchanged <file>, but this is only for the local repo and may complicate things further down the line.

I think the best way to solve this is to rename it to paths.make.default, keep this in the repo, maybe with <your-path-here> instead of your path, and have people make their own paths.make from that one. We track changes to paths.make.default and ignore paths.make. What do you think?

[arturoc]

yes that seems a great idea let it like it is by now and remove the gitignore if it's not working. i'll change it later but need the setup guide to be consistent with the repo.

thanks!

a

El 28/03/2012, a las 14:09, Christoph Buchner escribió:

But currently (because it's already tracked) changes to it appear in git status, so I think this solution doesn't actually work at all. E.g. 580d608#diff-1

One way would be to do git update-index --assume-unchanged <file>, but this is only for the local repo and may complicate things further down the line.

I think the best way to solve this is to rename it to paths.make.default, keep this in the repo, maybe with <your-path-here> instead of your path, and have people make their own paths.make from that one. We track changes to paths.make.default and ignore paths.make. What do you think?

---

Reply to this email directly or view it on GitHub:
#1081 (comment)

[bilderbuchi]

Will do! I'll put my solution into a separate issue (so we remember).

[arturoc]

yes please, even if you want to send a PR and i'll merge it as soon as i can fix the docs that would be great!

thanks!

El 28/03/2012, a las 14:13, Christoph Buchner escribió:

Will do! Should I put my solution into a separate issue (so we remember)?

---

Reply to this email directly or view it on GitHub:
#1081 (comment)

[bilderbuchi]

Done. See #1118. As I mentioned there, how do we deal with when the makefile does not find the customized paths.make? If you tell/code me that, I can do the PR. Let's continue discussion there.