You could also put a .gitignore in the gt-jdbc-h2 folder. But I suppose if
you are really the only one working on it then it doesn't make too much
difference one way or the other.
--
David Winslow
OpenGeo - http://opengeo.org/
On Tue, Jul 3, 2012 at 1:44 AM, Ben Caradoc-Davies <
ben.caradoc-dav...@csiro.au> wrote:
> Short version:
>
> Adding ignores to .git/info/exclude allows me to supplement a .gitignore
> under source control with the extra project-specific ignores I need, so let
> us put the ignores everyone needs in .gitignore under source control.
>
> Long version:
>
> I see that Justin has already added a .gitignore file. I immediately have
> the problem that it is incomplete because it does not contain the cruft
> gt-jdbc-h2 dumps outside its target:
>
> $ git st
> # On branch master
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # modules/plugin/jdbc/jdbc-h2/**null.2.log.db
> # modules/plugin/jdbc/jdbc-h2/**null.data.db
> # modules/plugin/jdbc/jdbc-h2/**null.index.db
> # modules/plugin/jdbc/jdbc-h2/**null.trace.db
> nothing added to commit but untracked files present (use "git add" to
> track)
>
> Are we going to add these to .gitignore for cruft from every unsupported
> module that almost nobody builds? Should I as a user be adding
> project-specific .gitignores to my global configuration to overcome
> problems in a project .gitignore under source control? At least with git,
> non-committers can work around a .gitignore in the remote repo by fixing it
> in a local branch, so this is not as bad a problem as in subversion. But
> that would still be an ugly hack.
>
> A better solution is to add the following to my GeoTools local repo
> .git/info/exclude:
>
> modules/plugin/jdbc/jdbc-h2/**null.2.log.db
> modules/plugin/jdbc/jdbc-h2/**null.data.db
> modules/plugin/jdbc/jdbc-h2/**null.index.db
> modules/plugin/jdbc/jdbc-h2/**null.trace.db
>
> This file is not source-controlled. Then:
>
> $ git st
> # On branch master
> nothing to commit (working directory clean)
>
> So, problem solved, and we have the best of both worlds, without polluting
> a user's global settings.
>
> Kind regards,
> Ben.
>
> On 02/07/12 22:12, David Winslow wrote:
>
>> Git supports a user-specific .gitignore file - as described here:
>> https://help.github.com/**articles/ignoring-files<https://help.github.com/articles/ignoring-files>.
>> It's additive - so
>> both ignore lists are considered when determining which files to ignore.
>>
>> Would it make sense to commit a .gitignore for GeoTools with the things
>> that are produced by the GeoTools build (.pyc, target/) and leave
>> tool-specific things like .classpath up to the global ignore file?
>>
>> --
>> David Winslow
>> OpenGeo - http://opengeo.org/
>>
>> On Mon, Jul 2, 2012 at 9:08 AM, Jody Garnett <jody.garn...@gmail.com
>> <mailto:jody.garn...@gmail.com**>> wrote:
>>
>> Then we will really need to add this to the instructions (or risk
>> target folders being committed)
>>
>> --
>> Jody Garnett
>>
>> On 02/07/2012, at 4:14 PM, Ben Caradoc-Davies
>> <ben.caradoc-dav...@csiro.au> wrote:
>>
>> > No, no, never commit .gitignore. Mine always starts with
>> .gitignore :-)
>> >
>> > The advantage of a local-only .gitignore is that every user can
>> adapt their .gitignore to their local build tools (netbeans ...). If
>> there is one thing I learned from svn it its that svn:ignore is an
>> antipattern; it exposes local details to the community.
>> >
>> > On 02/07/12 11:54, Jody Garnett wrote:
>> >> should we consider committing one of these now that we are all
>> using git?
>> >
>> > --
>> > Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
>> > Software Engineer
>> > CSIRO Earth Science and Resource Engineering
>> > Australian Resources Research Centre
>> >
>> >
>>
>> ------------------------------**------------------------------**
>> ------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions
>> will include endpoint security, mobile security and the latest in
>> malware
>> threats.
>> http://www.accelacomm.com/jaw/**sfrnl04242012/114/50122263/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>> ______________________________**_________________
>> GeoTools-Devel mailing list
>>
>> GeoTools-Devel@lists.**sourceforge.net<GeoTools-Devel@lists.sourceforge.net>
>>
>> <mailto:GeoTools-Devel@lists.**sourceforge.net<GeoTools-Devel@lists.sourceforge.net>
>> >
>>
>> https://lists.sourceforge.net/**lists/listinfo/geotools-devel<https://lists.sourceforge.net/lists/listinfo/geotools-devel>
>>
>>
>>
> --
> Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
