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