* James Cloos:
> I'm reading this a bit late, but...
>
> We (Xorg) found that ignoring:
>
>*~
>*.bak
>*.patch
>
> in addition to the files generated by building is very helpful.
I tend to put those into .git/info/exclude. They are somewhat
developer-specific, after all.
--
Florian
On Oct 10, 2010, at 12:57 AM, Gurjeet Singh wrote:
> On Tue, Sep 21, 2010 at 12:55 AM, Robert Haas wrote:
> All the build products in a normal build. One of the infelicities of
> git is that 'git status' shows the untracked files at the bottom. So
> if you have lots of unignored stuff floating
On Tue, Sep 21, 2010 at 12:55 AM, Robert Haas wrote:
> All the build products in a normal build. One of the infelicities of
> git is that 'git status' shows the untracked files at the bottom. So
> if you have lots of unignored stuff floating around, the information
> about which files you've ac
James Cloos writes:
> I'm reading this a bit late, but...
> We (Xorg) found that ignoring:
>*~
>*.bak
>*.patch
> in addition to the files generated by building is very helpful.
Yeah ... personally I'm ignoring *~ and *.orig. I think that the
consensus among pgsql-hackers was that t
I'm reading this a bit late, but...
We (Xorg) found that ignoring:
*~
*.bak
*.patch
in addition to the files generated by building is very helpful.
We do use git tag and git describe in the make dist process, as
well as git log >ChangeLog. That may be relevant; avoiding git
describe's
On Thu, Sep 23, 2010 at 7:58 PM, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>
>> Ok. Just to be clear, here's what I have now
>
> Here's one I found that got missed. (Perhaps you need to configure
> --with-libxml to get it.)
Looks like it. Committed and back-patched to 8.0.
--
Robert Haa
Magnus Hagander wrote:
> Ok. Just to be clear, here's what I have now
Here's one I found that got missed. (Perhaps you need to configure
--with-libxml to get it.)
-Kevin
*** a/contrib/xml2/.gitignore
--- b/contrib/xml2/.gitignore
***
*** 1,2
--- 1,3
+ /pgxml.sql
# G
On Tue, Sep 21, 2010 at 22:11, Tom Lane wrote:
> I wrote:
>> Magnus Hagander writes:
>>> Do we know what the exact pattern would be for .sl and .dylib? Are
>>> they following the same basic pattern of .sl..?
>
>> Yes, they'll be just the same --- Makefile.shlib treats all those
>> extensions alik
On Wed, Sep 22, 2010 at 20:38, Tom Lane wrote:
> Magnus Hagander writes:
>> On Wed, Sep 22, 2010 at 20:28, Kevin Grittner
>> wrote:
>>> Magnus Hagander wrote:
>>>
>> Done and applied.
>>>
>>> I just did `make world`, `make check`, `sudo make install-world`, and
>>> `make installcheck-world`. I
Magnus Hagander writes:
> On Wed, Sep 22, 2010 at 20:28, Kevin Grittner
> wrote:
>> Magnus Hagander wrote:
>>
> Done and applied.
>>
>> I just did `make world`, `make check`, `sudo make install-world`, and
>> `make installcheck-world`. I was left with these showing in my `git
>> status`:
> A
On Wed, Sep 22, 2010 at 20:28, Kevin Grittner
wrote:
> Magnus Hagander wrote:
>
>> Done and applied.
>
> I just did `make world`, `make check`, `sudo make install-world`, and
> `make installcheck-world`. I was left with these showing in my `git
> status`:
Ahh. Clearly I didn't run the regressio
Magnus Hagander wrote:
> Done and applied.
I just did `make world`, `make check`, `sudo make install-world`, and
`make installcheck-world`. I was left with these showing in my `git
status`:
# Untracked files:
# (use "git add ..." to
On Tue, Sep 21, 2010 at 22:23, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 22:15, Tom Lane wrote:
>>> Global patterns look ok to me. Thought you were going to stick leading
>>> slashes on all the others?
>
>> Oh, misunderstood. I thought the idea was just slashes in the
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 22:15, Tom Lane wrote:
>> Global patterns look ok to me. Thought you were going to stick leading
>> slashes on all the others?
> Oh, misunderstood. I thought the idea was just slashes in the
> top-level ones, not the leaf ones. But I'll add it t
On Tue, Sep 21, 2010 at 22:15, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 22:11, Tom Lane wrote:
>>> So it looks like *.dylib is sufficient and we don't need anything with
>>> numbers afterwards for that variant.
>
>> Ok. Just to be clear, here's what I have now:
>
> Gl
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 22:11, Tom Lane wrote:
>> So it looks like *.dylib is sufficient and we don't need anything with
>> numbers afterwards for that variant.
> Ok. Just to be clear, here's what I have now:
Global patterns look ok to me. Thought you were going to st
I wrote:
> Magnus Hagander writes:
>> Do we know what the exact pattern would be for .sl and .dylib? Are
>> they following the same basic pattern of .sl..?
> Yes, they'll be just the same --- Makefile.shlib treats all those
> extensions alike.
I take that back. Darwin does things differently, b
On 09/21/2010 03:43 PM, Magnus Hagander wrote:
Hmm. Hold on.
My gitignore manpage doesn't say anything about supporting regular
expressions at all. And actually adding the line proposed by Peter
doesn't work.
What works is adding all of:
*.so
*.so.[0-9]
*.so.[0-9].[0-9]
That will break if t
Magnus Hagander writes:
> My gitignore manpage doesn't say anything about supporting regular
> expressions at all. And actually adding the line proposed by Peter
> doesn't work.
Yeah, I was wondering about that. They're meant to be shell patterns
not regexps, I think.
> What works is adding all
On Tue, Sep 21, 2010 at 21:32, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 20:59, Tom Lane wrote:
>>> Just paranoia, I guess. I can't actually see a reason why we'd have
>>> any committable files in the tree matching that pattern. OTOH, we
>>> probably also need the sa
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 20:59, Tom Lane wrote:
>> Just paranoia, I guess. I can't actually see a reason why we'd have
>> any committable files in the tree matching that pattern. OTOH, we
>> probably also need the same type of pattern for .sl and .dylib,
>> so at some p
On Tue, Sep 21, 2010 at 20:59, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut wrote:
>>> On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
rather than global ignore patterns for *.a and *.so.[0-9]
>>>
>>> Probably rather *.so.[0-9.]+
>
>> Any p
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut wrote:
>> On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
>>> rather than global ignore patterns for *.a and *.so.[0-9]
>>
>> Probably rather *.so.[0-9.]+
> Any particular reason not to just do .so.*?
Just paranoia, I
On Tue, Sep 21, 2010 at 20:29, Tom Lane wrote:
> Magnus Hagander writes:
>> Have we decided to do this? If so, I'll start backpatching it...
>
> Yeah, go for it.
>
> BTW, a look at the recommended GitExclude on the wiki suggests that
> we need these two additional global exclusions:
>
> *.
On Tue, Sep 21, 2010 at 20:21, Peter Eisentraut wrote:
> On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
>> rather than global ignore patterns for *.a and *.so.[0-9]
>
> Probably rather *.so.[0-9.]+
Any particular reason not to just do .so.*?
--
Magnus Hagander
Me: http://www.hagander.net
Magnus Hagander writes:
> Have we decided to do this? If so, I'll start backpatching it...
Yeah, go for it.
BTW, a look at the recommended GitExclude on the wiki suggests that
we need these two additional global exclusions:
*.mo... for NLS builds
*.dylib ...
On tis, 2010-09-21 at 11:27 -0400, Tom Lane wrote:
> rather than global ignore patterns for *.a and *.so.[0-9]
Probably rather *.so.[0-9.]+
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hacker
On Tue, Sep 21, 2010 at 19:46, Tom Lane wrote:
> Magnus Hagander writes:
>> On Tue, Sep 21, 2010 at 17:27, Tom Lane wrote:
>>> Why does this entry have a / when none of the rest do? Shouldn't
>>> we be consistent about that?
>
>> We should. I've removed it.
>
>> The difference is that "zic" mat
Magnus Hagander writes:
> On Tue, Sep 21, 2010 at 17:27, Tom Lane wrote:
>> Why does this entry have a / when none of the rest do? Shouldn't
>> we be consistent about that?
> We should. I've removed it.
> The difference is that "zic" matches zic in any subdirectory and
> "/zic" matches just in
On Tue, Sep 21, 2010 at 17:27, Tom Lane wrote:
> Magnus Hagander writes:
>> Breaking it up was quite trivial. Here's what I came up with after
>> building on my box. I'm sure there are some on other platforms showing
>> up, but this should be the majority.
>
>> I just realized it does not include
At 2010-09-21 11:02:30 -0400, t...@sss.pgh.pa.us wrote:
>
> So you really do need git ignore to ignore all build products;
> otherwise you'll have lots of chatter in "git status".
Right.
I usually put build products into a top-level build directory and put
"build/" in my top-level .gitignore (but
On 09/21/2010 11:20 AM, Heikki Linnakangas wrote:
On 21/09/10 18:02, Tom Lane wrote:
Peter Eisentraut writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
3. What are the ignore filesets *for*, in particular should they list
just the derived files expected in a distribution tarball, o
Magnus Hagander writes:
> Breaking it up was quite trivial. Here's what I came up with after
> building on my box. I'm sure there are some on other platforms showing
> up, but this should be the majority.
> I just realized it does not include contrib, but's that a mechanical
> copy of the same th
On 21/09/10 18:02, Tom Lane wrote:
Peter Eisentraut writes:
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
3. What are the ignore filesets *for*, in particular should they list
just the derived files expected in a distribution tarball, or all the
files in the set of build products in a nor
On tis, 2010-09-21 at 14:12 +0200, Magnus Hagander wrote:
> Breaking it up was quite trivial. Here's what I came up with after
> building on my box. I'm sure there are some on other platforms showing
> up, but this should be the majority.
Note that shared library names are platform dependent.
--
On Tue, Sep 21, 2010 at 11:02 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
>>> 3. What are the ignore filesets *for*, in particular should they list
>>> just the derived files expected in a distribution tarball, or all the
>>> files in the s
Peter Eisentraut writes:
> On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
>> 3. What are the ignore filesets *for*, in particular should they list
>> just the derived files expected in a distribution tarball, or all the
>> files in the set of build products in a normal build?
> My personal vo
On Tue, Sep 21, 2010 at 8:12 AM, Magnus Hagander wrote:
> Breaking it up was quite trivial. Here's what I came up with after
> building on my box. I'm sure there are some on other platforms showing
> up, but this should be the majority.
>
> I just realized it does not include contrib, but's that a
On tis, 2010-09-21 at 00:00 -0400, Tom Lane wrote:
> 3. What are the ignore filesets *for*, in particular should they list
> just the derived files expected in a distribution tarball, or all the
> files in the set of build products in a normal build?
My personal vote: Forget the whole thing.
I ha
On Tue, Sep 21, 2010 at 16:27, Peter Eisentraut wrote:
> On tis, 2010-09-21 at 00:55 -0400, Robert Haas wrote:
>> One of the infelicities of
>> git is that 'git status' shows the untracked files at the bottom. So
>> if you have lots of unignored stuff floating around, the information
>> about whi
On tis, 2010-09-21 at 00:55 -0400, Robert Haas wrote:
> One of the infelicities of
> git is that 'git status' shows the untracked files at the bottom. So
> if you have lots of unignored stuff floating around, the information
> about which files you've actually changed or added to the index
> scrol
On Tue, Sep 21, 2010 at 13:12, Robert Haas wrote:
> On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I suppose you already know my votes, but here they are again just in case.
>>> ...
>>> Centralize.
>>> ...
>>> All the build products in a normal build.
>>
>> I don't u
On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane wrote:
> Robert Haas writes:
>> I suppose you already know my votes, but here they are again just in case.
>> ...
>> Centralize.
>> ...
>> All the build products in a normal build.
>
> I don't understand your preference for this together with a centralize
On Tue, Sep 21, 2010 at 06:00, Tom Lane wrote:
> Back here I asked what we were going to do about .gitignore files:
> http://archives.postgresql.org/pgsql-hackers/2010-08/msg01232.php
> The thread died off when the first git conversion attempt crashed and
> burned; but not before it became apparen
Robert Haas writes:
> I suppose you already know my votes, but here they are again just in case.
> ...
> Centralize.
> ...
> All the build products in a normal build.
I don't understand your preference for this together with a centralized
ignore file. That will be completely unmaintainable IMNSH
I suppose you already know my votes, but here they are again just in case.
On Tue, Sep 21, 2010 at 12:00 AM, Tom Lane wrote:
> 1. Whether to keep the per-subdirectory ignore files (which CVS
> insisted on, but git doesn't) or centralize in a single ignore file.
Centralize.
> 2. Whether to have
Back here I asked what we were going to do about .gitignore files:
http://archives.postgresql.org/pgsql-hackers/2010-08/msg01232.php
The thread died off when the first git conversion attempt crashed and
burned; but not before it became apparent that we didn't have much
consensus. It seemed that th
47 matches
Mail list logo
