On 08/12/2015 09:52 PM, Mike Frysinger wrote:
On 12 Aug 2015 18:27, Brian Dolbec wrote:
2) There is another alternate location that you can define files to
ignore locally without having to commit them to .gitignore.
Consider .gitignore a global setting. There is another setting
inside .git/info/exclude which is a local config file that will persist
and not be affected by pulls.
So please use that for local exclusions you want to add and not try to
force them into a global .gitignore which is part of the repo.
Something that seems to be hotly debated. ;)
as i stated, there's no reason for these paths to ever be committed.
conversely, some people (not unreasonably so) will place files in there
that have historically had known meanings. adding these to the global
gitignore is simply the right thing to do and negatively impacts no one.
-mike
As a gentoo user now coding again, I find the need to have things
"logically organized" really helps in my efforts. Like most others, I
get codes from a variety of places and try to follow the 'logical gentoo
organization'. I use /usr/local/portage extensively for ebuilds
that I develop. There is also /opt/ which seems to collect up a variety
of ebuilds. Some, are there as part of their lineage that nobody bothered
to change (net-analyzer/jffnms) others are there for license or 'fit'
reasons.... Maybe a survey of codes placed into /opt/ should also be
examined as part of these migration efforts?
I also experiment around with a variety of sources and I think (old bsd
habits) that these should also be under /usr/local/. My point is this::
please keep in mind those that use gentoo for software development
outside the dev teams as they have needs for logical organization that
mostly follows the 'gentoo way' as you devs finalize the 'gentoo way'
for code(s) management. Combined with this is the need to organize where
the gentoo community should push their ebuilds which will end up being
pushed towards the portage tree. I.E. clearly define the pathways like
Sunrise, user-overlays and the corresponding admin semantics. Otherwise
we'll end up with lots of viable but unique pathways and that will just
add to the support burden on lists like gentoo user and for those
mentors as well as the 'preferred or consensus' configuration for git by
user's coding needs.
hth,
James
