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 there was lack of agreement as to:

1. Whether to keep the per-subdirectory ignore files (which CVS
insisted on, but git doesn't) or centralize in a single ignore file.

2. Whether to have the ignore files ignore common cruft such as
editor backup files, or only "expected" build product files.

It was pointed out that exclusion rules could be configured locally
to one's own repository, so one possible answer to issue #2 is to
have only a minimal ignore-set embodied in .gitignore files, and let
people who prefer to ignore more stuff set that up in local preferences.

Although this point wasn't really brought up during that thread, it's
also the case that the existing implementation is far from consistent
about ignoring build products. We really only have .cvsignore entries
for files that are not in CVS but are meant to be present in
distribution tarballs. CVS will, of its own accord, ignore certain
build products such as .o files; but it doesn't ignore executables for
instance. So unless you do a "make distclean" before "cvs update",
you will get notices about non-ignored files. That never bothered me
particularly but I believe it annoys some other folks. So really there
is a third area of disagreement:

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?

We need to get some consensus on this now. Comments?

regards, tom lane

Search Discussions

  • Robert Haas at Sep 21, 2010 at 4:56 am
    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 the ignore files ignore common cruft such as
    editor backup files, or only "expected" build product files.
    I don't care too much about this. A mild preference for just the
    expected build product files, but then that's heavily influenced by my
    choice of editor, which doesn't leave such cruft around permanently.
    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?
    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 actually changed or added to the index
    scrolls right off the screen.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Tom Lane at Sep 21, 2010 at 5:07 am

    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 IMNSHO. A
    centralized file would work all right if it's limited to the couple
    dozen files that are currently listed in .cvsignore's, but I can't see
    doing it that way if it has to list every executable and .so built
    anywhere in the tree. You'd get merge conflicts from
    completely-unrelated patches, not to mention the fundamental
    action-at-a-distance nastiness of a top-level file that knows about
    everything going on in every part of the tree.

    To put it another way: would you expect anyone to take it seriously
    if you proposed moving all the "make clean" rules into the top-level
    Makefile? That's pretty much exactly what this would be.

    regards, tom lane
  • Robert Haas at Sep 21, 2010 at 11:12 am

    On Tue, Sep 21, 2010 at 1:06 AM, Tom Lane wrote:
    Robert Haas <robertmhaas@gmail.com> 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 IMNSHO.  A
    centralized file would work all right if it's limited to the couple
    dozen files that are currently listed in .cvsignore's, but I can't see
    doing it that way if it has to list every executable and .so built
    anywhere in the tree.  You'd get merge conflicts from
    completely-unrelated patches, not to mention the fundamental
    action-at-a-distance nastiness of a top-level file that knows about
    everything going on in every part of the tree.
    Oh. I was just figuring it would be pretty easy to regenerate from
    the output of git status. You might have merge conflicts but they'll
    be trivial. But then again, the effort of breaking up the output of
    git status into individual per-directory files is probably largely a
    one-time effort, so maybe it doesn't matter very much.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Magnus Hagander at Sep 21, 2010 at 12:12 pm

    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 <robertmhaas@gmail.com> 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 IMNSHO.  A
    centralized file would work all right if it's limited to the couple
    dozen files that are currently listed in .cvsignore's, but I can't see
    doing it that way if it has to list every executable and .so built
    anywhere in the tree.  You'd get merge conflicts from
    completely-unrelated patches, not to mention the fundamental
    action-at-a-distance nastiness of a top-level file that knows about
    everything going on in every part of the tree.
    Oh.  I was just figuring it would be pretty easy to regenerate from
    the output of git status.  You might have merge conflicts but they'll
    be trivial.  But then again, the effort of breaking up the output of
    git status into individual per-directory files is probably largely a
    one-time effort, so maybe it doesn't matter very much.
    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 thing.

    So if we want to go with this way, i have the scripts/changes ready :)
  • Robert Haas at Sep 21, 2010 at 2:38 pm

    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 mechanical
    copy of the same thing.

    So if we want to go with this way, i have the scripts/changes ready :)
    Sounds good to me.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Peter Eisentraut at Sep 21, 2010 at 3:13 pm

    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.
  • Tom Lane at Sep 21, 2010 at 3:27 pm

    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 thing.
    So if we want to go with this way, i have the scripts/changes ready :)
    This works for me, modulo some things:

    If we are going to ignore *.so at the top level, we also need to ignore
    *.sl (for HPUX) and *.dll (for Windows). I also wonder why we have
    entries like this:
    +libecpg.a
    +libecpg.so.*
    rather than global ignore patterns for *.a and *.so.[0-9]

    We should probably ignore src/Makefile.custom, since that is still a
    supported way to customize builds (and some of us still use it).
    diff --git a/src/timezone/.gitignore b/src/timezone/.gitignore
    new file mode 100644
    index 0000000..f844c9f
    --- /dev/null
    +++ b/src/timezone/.gitignore
    @@ -0,0 +1 @@
    +/zic
    Why does this entry have a / when none of the rest do? Shouldn't
    we be consistent about that?

    regards, tom lane
  • Magnus Hagander at Sep 21, 2010 at 5:18 pm

    On Tue, Sep 21, 2010 at 17:27, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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 thing.
    So if we want to go with this way, i have the scripts/changes ready :)
    This works for me, modulo some things:

    If we are going to ignore *.so at the top level, we also need to ignore
    *.sl (for HPUX) and *.dll (for Windows).  I also wonder why we have
    *.sl was missing because I didn't know about it.
    *.dll was missing because on msvc we always build out of tree. And I
    forgot about mingw not doing that :-)

    entries like this:
    +libecpg.a
    +libecpg.so.*
    rather than global ignore patterns for *.a and *.so.[0-9]
    Yeah, that seems better.

    We should probably ignore src/Makefile.custom, since that is still a
    supported way to customize builds (and some of us still use it).
    Ok, added.

    diff --git a/src/timezone/.gitignore b/src/timezone/.gitignore
    new file mode 100644
    index 0000000..f844c9f
    --- /dev/null
    +++ b/src/timezone/.gitignore
    @@ -0,0 +1 @@
    +/zic
    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 the top dir. But we're not having any other
    thing called zic further down - it's really only a potential problem
    at the top level.

    How's this?


    Btw, what's the "stamp-h" file? Should that be excluded globally?
  • Tom Lane at Sep 21, 2010 at 5:46 pm

    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 the top dir. But we're not having any other
    thing called zic further down - it's really only a potential problem
    at the top level.
    Hmm. In leaf subdirectories it doesn't matter of course, but I'm
    worried about .gitignore files in non-leaf subdirectories accidentally
    excluding files further down the tree. Wouldn't it be better to
    standardize on always using the slash, rather than not using it?
    Btw, what's the "stamp-h" file? Should that be excluded globally?
    I'd say no, there's only one or two instances.

    regards, tom lane
  • Magnus Hagander at Sep 21, 2010 at 6:11 pm

    On Tue, Sep 21, 2010 at 19:46, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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 the top dir. But we're not having any other
    thing called zic further down - it's really only a potential problem
    at the top level.
    Hmm.  In leaf subdirectories it doesn't matter of course, but I'm
    worried about .gitignore files in non-leaf subdirectories accidentally
    excluding files further down the tree.  Wouldn't it be better to
    standardize on always using the slash, rather than not using it?
    Yeah, good point. I just took the path of least resistance :-) I'll
    update with that before commit.

    Have we decided to do this? If so, I'll start backpatching it...
    Btw, what's the "stamp-h" file? Should that be excluded globally?
    I'd say no, there's only one or two instances.
    Ok. Since I don't know what it is, I didn't know if it's likely to pop
    up anywhere else under different circumstances.
  • Tom Lane at Sep 21, 2010 at 6:30 pm

    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 ... Darwin spelling of *.so

    regards, tom lane
  • Magnus Hagander at Sep 21, 2010 at 6:46 pm

    On Tue, Sep 21, 2010 at 20:29, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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         ... Darwin spelling of *.so
    Added to list.
  • Peter Eisentraut at Sep 21, 2010 at 6:22 pm

    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.]+
  • Magnus Hagander at Sep 21, 2010 at 6:36 pm

    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.*?
  • Tom Lane at Sep 21, 2010 at 6:59 pm

    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 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 point a more conservative pattern would be wise.

    regards, tom lane
  • Magnus Hagander at Sep 21, 2010 at 7:01 pm

    On Tue, Sep 21, 2010 at 20:59, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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 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 point a more conservative pattern would be wise.
    Do we know what the exact pattern would be for .sl and .dylib? Are
    they following the same basic pattern of .sl.<major>.<minor>?
  • Tom Lane at Sep 21, 2010 at 7:32 pm

    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 point a more conservative pattern would be wise.
    Do we know what the exact pattern would be for .sl and .dylib? Are
    they following the same basic pattern of .sl.<major>.<minor>?
    Yes, they'll be just the same --- Makefile.shlib treats all those
    extensions alike.

    regards, tom lane
  • Magnus Hagander at Sep 21, 2010 at 7:43 pm

    On Tue, Sep 21, 2010 at 21:32, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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 point a more conservative pattern would be wise.
    Do we know what the exact pattern would be for .sl and .dylib? Are
    they following the same basic pattern of .sl.<major>.<minor>?
    Yes, they'll be just the same --- Makefile.shlib treats all those
    extensions alike.
    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 there's a two-digit number, i guess. Do we want to
    go with that anyway?
  • Tom Lane at Sep 21, 2010 at 8:15 pm

    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 of:
    *.so
    *.so.[0-9]
    *.so.[0-9].[0-9]
    That will break if there's a two-digit number, i guess. Do we want to
    go with that anyway?
    What we can do, when and if any of those numbers get to two digits,
    is add

    *.so.[0-9][0-9]

    etc etc. Which would not need to be back-patched. So let's just go in
    that direction.

    regards, tom lane
  • Andrew Dunstan at Sep 21, 2010 at 8:15 pm

    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 there's a two-digit number, i guess. Do we want to
    go with that anyway?
    They are shell globs. You could just add more patterns for the two digit
    cases if you care about it. It would be four more patterns for .so*

    cheers

    andrew
  • Tom Lane at Sep 21, 2010 at 8:15 pm

    I wrote:
    Magnus Hagander <magnus@hagander.net> writes:
    Do we know what the exact pattern would be for .sl and .dylib? Are
    they following the same basic pattern of .sl.<major>.<minor>?
    Yes, they'll be just the same --- Makefile.shlib treats all those
    extensions alike.
    I take that back. Darwin does things differently, bless their pointy
    little heads:

    DLSUFFIX = .dylib
    shlib = lib$(NAME).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)$(DLSUFFIX)

    So it looks like *.dylib is sufficient and we don't need anything with
    numbers afterwards for that variant.

    regards, tom lane
  • Magnus Hagander at Sep 21, 2010 at 8:16 pm

    On Tue, Sep 21, 2010 at 22:11, Tom Lane wrote:
    I wrote:
    Magnus Hagander <magnus@hagander.net> writes:
    Do we know what the exact pattern would be for .sl and .dylib? Are
    they following the same basic pattern of .sl.<major>.<minor>?
    Yes, they'll be just the same --- Makefile.shlib treats all those
    extensions alike.
    I take that back.  Darwin does things differently, bless their pointy
    little heads:

    DLSUFFIX            = .dylib
    shlib               = lib$(NAME).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)$(DLSUFFIX)

    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:
  • Tom Lane at Sep 21, 2010 at 8:16 pm

    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 stick leading
    slashes on all the others?

    regards, tom lane
  • Magnus Hagander at Sep 21, 2010 at 8:18 pm

    On Tue, Sep 21, 2010 at 22:15, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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 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 to those as well
    then :-)
  • Tom Lane at Sep 21, 2010 at 8:23 pm

    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 to those as well
    then :-)
    I think it'd be wise to have a convention of leading slash anywhere
    the pattern is not meant to be global. It won't matter to git in
    leaf dirs, but it might prevent somebody from making a copy-and-paste
    error later; or perhaps more likely, might prevent a problem if what
    had been a leaf directory acquires children.

    regards, tom lane
  • Magnus Hagander at Sep 22, 2010 at 12:11 pm

    On Tue, Sep 21, 2010 at 22:23, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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 to those as well
    then :-)
    I think it'd be wise to have a convention of leading slash anywhere
    the pattern is not meant to be global.  It won't matter to git in
    leaf dirs, but it might prevent somebody from making a copy-and-paste
    error later; or perhaps more likely, might prevent a problem if what
    had been a leaf directory acquires children.
    Done and applied.
  • Kevin Grittner at Sep 22, 2010 at 6:28 pm

    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 <file>..." to include in what will be committed)

    #

    # contrib/btree_gin/results/

    # contrib/btree_gist/results/

    # contrib/citext/results/

    # contrib/cube/results/

    # contrib/dblink/results/

    # contrib/dict_int/results/

    # contrib/dict_xsyn/results/

    # contrib/earthdistance/results/

    # contrib/hstore/results/

    # contrib/intarray/results/

    # contrib/ltree/results/

    # contrib/pg_trgm/results/

    # contrib/pgcrypto/results/

    # contrib/seg/results/

    # contrib/tablefunc/results/

    # contrib/test_parser/results/

    # contrib/tsearch2/results/

    # contrib/unaccent/results/

    # contrib/xml2/pgxml.sql

    # contrib/xml2/results/

    # doc/src/sgml/HTML.index

    # doc/src/sgml/bookindex.sgml

    # doc/src/sgml/postgres.xml

    # src/interfaces/ecpg/test/compat_informix/charfuncs

    # src/interfaces/ecpg/test/compat_informix/charfuncs.c

    # src/interfaces/ecpg/test/compat_informix/dec_test

    # src/interfaces/ecpg/test/compat_informix/dec_test.c

    # src/interfaces/ecpg/test/compat_informix/describe

    # src/interfaces/ecpg/test/compat_informix/describe.c

    # src/interfaces/ecpg/test/compat_informix/rfmtdate

    # src/interfaces/ecpg/test/compat_informix/rfmtdate.c

    # src/interfaces/ecpg/test/compat_informix/rfmtlong

    # src/interfaces/ecpg/test/compat_informix/rfmtlong.c

    # src/interfaces/ecpg/test/compat_informix/rnull

    # src/interfaces/ecpg/test/compat_informix/rnull.c

    # src/interfaces/ecpg/test/compat_informix/sqlda

    # src/interfaces/ecpg/test/compat_informix/sqlda.c

    # src/interfaces/ecpg/test/compat_informix/test_informix

    # src/interfaces/ecpg/test/compat_informix/test_informix.c

    # src/interfaces/ecpg/test/compat_informix/test_informix2

    # src/interfaces/ecpg/test/compat_informix/test_informix2.c

    # src/interfaces/ecpg/test/connect/test1

    # src/interfaces/ecpg/test/connect/test1.c

    # src/interfaces/ecpg/test/connect/test2

    # src/interfaces/ecpg/test/connect/test2.c

    # src/interfaces/ecpg/test/connect/test3

    # src/interfaces/ecpg/test/connect/test3.c

    # src/interfaces/ecpg/test/connect/test4

    # src/interfaces/ecpg/test/connect/test4.c

    # src/interfaces/ecpg/test/connect/test5

    # src/interfaces/ecpg/test/connect/test5.c

    # src/interfaces/ecpg/test/pg_regress

    # src/interfaces/ecpg/test/pgtypeslib/dt_test

    # src/interfaces/ecpg/test/pgtypeslib/dt_test.c

    # src/interfaces/ecpg/test/pgtypeslib/dt_test2

    # src/interfaces/ecpg/test/pgtypeslib/dt_test2.c

    # src/interfaces/ecpg/test/pgtypeslib/nan_test

    # src/interfaces/ecpg/test/pgtypeslib/nan_test.c

    # src/interfaces/ecpg/test/pgtypeslib/num_test

    # src/interfaces/ecpg/test/pgtypeslib/num_test.c

    # src/interfaces/ecpg/test/pgtypeslib/num_test2

    # src/interfaces/ecpg/test/pgtypeslib/num_test2.c

    # src/interfaces/ecpg/test/preproc/array_of_struct

    # src/interfaces/ecpg/test/preproc/array_of_struct.c

    # src/interfaces/ecpg/test/preproc/autoprep

    # src/interfaces/ecpg/test/preproc/autoprep.c

    # src/interfaces/ecpg/test/preproc/comment

    # src/interfaces/ecpg/test/preproc/comment.c

    # src/interfaces/ecpg/test/preproc/cursor

    # src/interfaces/ecpg/test/preproc/cursor.c

    # src/interfaces/ecpg/test/preproc/define

    # src/interfaces/ecpg/test/preproc/define.c

    # src/interfaces/ecpg/test/preproc/init

    # src/interfaces/ecpg/test/preproc/init.c

    # src/interfaces/ecpg/test/preproc/outofscope

    # src/interfaces/ecpg/test/preproc/outofscope.c

    # src/interfaces/ecpg/test/preproc/strings

    # src/interfaces/ecpg/test/preproc/strings.c

    # src/interfaces/ecpg/test/preproc/type

    # src/interfaces/ecpg/test/preproc/type.c

    # src/interfaces/ecpg/test/preproc/variable

    # src/interfaces/ecpg/test/preproc/variable.c

    # src/interfaces/ecpg/test/preproc/whenever

    # src/interfaces/ecpg/test/preproc/whenever.c

    # src/interfaces/ecpg/test/results/

    # src/interfaces/ecpg/test/sql/array

    # src/interfaces/ecpg/test/sql/array.c

    # src/interfaces/ecpg/test/sql/binary

    # src/interfaces/ecpg/test/sql/binary.c

    # src/interfaces/ecpg/test/sql/code100

    # src/interfaces/ecpg/test/sql/code100.c

    # src/interfaces/ecpg/test/sql/copystdout

    # src/interfaces/ecpg/test/sql/copystdout.c

    # src/interfaces/ecpg/test/sql/define

    # src/interfaces/ecpg/test/sql/define.c

    # src/interfaces/ecpg/test/sql/desc

    # src/interfaces/ecpg/test/sql/desc.c

    # src/interfaces/ecpg/test/sql/describe

    # src/interfaces/ecpg/test/sql/describe.c

    # src/interfaces/ecpg/test/sql/dynalloc

    # src/interfaces/ecpg/test/sql/dynalloc.c

    # src/interfaces/ecpg/test/sql/dynalloc2

    # src/interfaces/ecpg/test/sql/dynalloc2.c

    # src/interfaces/ecpg/test/sql/dyntest

    # src/interfaces/ecpg/test/sql/dyntest.c

    # src/interfaces/ecpg/test/sql/execute

    # src/interfaces/ecpg/test/sql/execute.c

    # src/interfaces/ecpg/test/sql/fetch

    # src/interfaces/ecpg/test/sql/fetch.c

    # src/interfaces/ecpg/test/sql/func

    # src/interfaces/ecpg/test/sql/func.c

    # src/interfaces/ecpg/test/sql/indicators

    # src/interfaces/ecpg/test/sql/indicators.c

    # src/interfaces/ecpg/test/sql/insupd

    # src/interfaces/ecpg/test/sql/insupd.c

    # src/interfaces/ecpg/test/sql/oldexec

    # src/interfaces/ecpg/test/sql/oldexec.c

    # src/interfaces/ecpg/test/sql/parser

    # src/interfaces/ecpg/test/sql/parser.c

    # src/interfaces/ecpg/test/sql/quote

    # src/interfaces/ecpg/test/sql/quote.c

    # src/interfaces/ecpg/test/sql/show

    # src/interfaces/ecpg/test/sql/show.c

    # src/interfaces/ecpg/test/sql/sqlda

    # src/interfaces/ecpg/test/sql/sqlda.c

    # src/interfaces/ecpg/test/thread/alloc

    # src/interfaces/ecpg/test/thread/alloc.c

    # src/interfaces/ecpg/test/thread/descriptor

    # src/interfaces/ecpg/test/thread/descriptor.c

    # src/interfaces/ecpg/test/thread/prep

    # src/interfaces/ecpg/test/thread/prep.c

    # src/interfaces/ecpg/test/thread/thread

    # src/interfaces/ecpg/test/thread/thread.c

    # src/interfaces/ecpg/test/thread/thread_implicit

    # src/interfaces/ecpg/test/thread/thread_implicit.c


    -Kevin
  • Magnus Hagander at Sep 22, 2010 at 6:33 pm

    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 regression tests for contrib and ecpg.

    I'll take a look at that.
  • Tom Lane at Sep 22, 2010 at 6:38 pm

    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`:
    Ahh. Clearly I didn't run the regression tests for contrib and ecpg.
    I'll take a look at that.
    I'm on it already for contrib and the PLs. But if you wanna do ecpg,
    that'd be helpful, because I forgot about that ...

    regards, tom lane
  • Magnus Hagander at Sep 22, 2010 at 7:59 pm

    On Wed, Sep 22, 2010 at 20:38, Tom Lane wrote:
    Magnus Hagander <magnus@hagander.net> 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`:
    Ahh. Clearly I didn't run the regression tests for contrib and ecpg.
    I'll take a look at that.
    I'm on it already for contrib and the PLs.   But if you wanna do ecpg,
    that'd be helpful, because I forgot about that ...
    Done.
  • Kevin Grittner at Sep 23, 2010 at 11:58 pm

    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
  • Robert Haas at Sep 24, 2010 at 2:27 am

    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 Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Peter Eisentraut at Sep 21, 2010 at 2:28 pm

    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
    scrolls right off the screen.
    Perhaps you knew this, but 'git status -uno' is moderately useful
    against that.
  • Magnus Hagander at Sep 21, 2010 at 2:32 pm

    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 which files you've actually changed or added to the index
    scrolls right off the screen.
    Perhaps you knew this, but 'git status -uno' is moderately useful
    against that.
    It is, but that one has the problem of not showing any untracked files
    - so if you forgot to add a file/directory you *wanted* to be added,
    it will also be hidden with -uno.
  • Gurjeet Singh at Oct 10, 2010 at 4:57 am

    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 actually changed or added to the index
    scrolls right off the screen.
    I have just started to read the thread, so don't know if somebody already
    chimed in.

    You can avoid the above situation by adding the folowing to ~/.gitconfig or
    .git/config

    [pager]
    status = true

    I think I used `git config` command for this, but adding by hand would also
    do.

    Regards,
    --
    gurjeet.singh
    @ EnterpriseDB - The Enterprise Postgres Company
    http://www.EnterpriseDB.com

    singh.gurjeet@{ gmail | yahoo }.com
    Twitter/Skype: singh_gurjeet

    Mail sent from my BlackLaptop device
  • Robert Haas at Oct 10, 2010 at 9:33 pm

    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 around, the information
    about which files you've actually changed or added to the index
    scrolls right off the screen.

    I have just started to read the thread, so don't know if somebody already chimed in.

    You can avoid the above situation by adding the folowing to ~/.gitconfig or .git/config

    [pager]
    status = true

    I think I used `git config` command for this, but adding by hand would also do.
    Oh, dude. Awesome.

    ...Robert
  • Magnus Hagander at Sep 21, 2010 at 7:00 am

    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 apparent that we didn't have much
    consensus.  It seemed that there was lack of agreement as to:

    1. Whether to keep the per-subdirectory ignore files (which CVS
    insisted on, but git doesn't) or centralize in a single ignore file.
    Both :-)

    If there are wildcard ones to be made ("*.o" - though that one I
    believe is excluded by default).

    Direct build targets should go in a local one - alongside the Makefile
    that builds them.

    2. Whether to have the ignore files ignore common cruft such as
    editor backup files, or only "expected" build product files.
    Editor backup files: no. That should be done locally, because everyone
    has a different editor which may have different ideas about that.
    Expected build product files: yes, because everybody gets those.

    Although this point wasn't really brought up during that thread, it's
    also the case that the existing implementation is far from consistent
    about ignoring build products.  We really only have .cvsignore entries
    for files that are not in CVS but are meant to be present in
    distribution tarballs.  CVS will, of its own accord, ignore certain
    build products such as .o files; but it doesn't ignore executables for
    instance.  So unless you do a "make distclean" before "cvs update",
    you will get notices about non-ignored files.  That never bothered me
    particularly but I believe it annoys some other folks.  So really there
    is a third area of disagreement:

    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?
    I would like to see us exclude all build products. That'll make "git
    status" a lot more useful (which it can be - whereas cvs status is
    always annoying), particularly if you're working with multiple
    branches and stashes and so.


    I assume once we have a decision, we're backporting this to all active
    branches, right?
  • Peter Eisentraut at Sep 21, 2010 at 2:38 pm

    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 have never found the .cvsignore files useful for anything, but they
    have only been a small annoyance when someone else quietly updated them
    when I supposedly forget. Some of the new proposed schemes
    for .gitignore appear to be significantly more involved.
  • Tom Lane at Sep 21, 2010 at 3:02 pm

    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 vote: Forget the whole thing.
    The folks who are more familiar with git than I seem to be pretty clear
    that we need to ignore all build products. I don't think that "ignore
    nothing" is going to work pleasantly at all. On reflection I realize
    that cvs ignore and git ignore are considerably different because they
    come into play at different times: cvs ignore really only matters while
    doing "cvs update" to pull in new code, while git ignore matters while
    you're constructing a commit. So you really do need git ignore to
    ignore all build products; otherwise you'll have lots of chatter in
    "git status".

    regards, tom lane
  • Robert Haas at Sep 21, 2010 at 3:13 pm

    On Tue, Sep 21, 2010 at 11:02 AM, Tom Lane wrote:
    Peter Eisentraut <peter_e@gmx.net> 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 vote: Forget the whole thing.
    The folks who are more familiar with git than I seem to be pretty clear
    that we need to ignore all build products.  I don't think that "ignore
    nothing" is going to work pleasantly at all.  On reflection I realize
    that cvs ignore and git ignore are considerably different because they
    come into play at different times: cvs ignore really only matters while
    doing "cvs update" to pull in new code, while git ignore matters while
    you're constructing a commit.  So you really do need git ignore to
    ignore all build products; otherwise you'll have lots of chatter in
    "git status".
    Back when I used CVS for anything, I used to use 'cvs -q update -d'
    somewhat the way I now use 'git status', so I've always been in favor
    of ignoring all the build products. But it is true that you tend to
    use 'git status' even a bit more, because you typically want to make
    sure you've staged everything correctly before committing (unless, of
    course, you always just do git commit -a, but that doesn't describe my
    workflow very well). At any rate, whatever the reasons, I'll be very,
    very happy if we can settle on a rule to ignore all build products.
    FWIW, "man gitignore" has these comments.

    # A project normally includes such .gitignore files
    # in its repository, containing patterns for files generated as part
    # of the project build.

    and further down:

    # Patterns which a user wants git to
    # ignore in all situations (e.g., backup or temporary files generated by
    # the user's editor of choice) generally go into a file specified by
    # core.excludesfile in the user's ~/.gitconfig.

    --
    Robert Haas
    EnterpriseDB: http://www.enterprisedb.com
    The Enterprise Postgres Company
  • Heikki Linnakangas at Sep 21, 2010 at 3:21 pm

    On 21/09/10 18:02, Tom Lane wrote:
    Peter Eisentraut<peter_e@gmx.net> 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 vote: Forget the whole thing.
    The folks who are more familiar with git than I seem to be pretty clear
    that we need to ignore all build products. I don't think that "ignore
    nothing" is going to work pleasantly at all. On reflection I realize
    that cvs ignore and git ignore are considerably different because they
    come into play at different times: cvs ignore really only matters while
    doing "cvs update" to pull in new code, while git ignore matters while
    you're constructing a commit. So you really do need git ignore to
    ignore all build products; otherwise you'll have lots of chatter in
    "git status".
    Agreed. It's not a big deal though, until now I've just always used "git
    status | less" and scrolled up to the beginning, ignoring the chatter.

    --
    Heikki Linnakangas
    EnterpriseDB http://www.enterprisedb.com
  • Andrew Dunstan at Sep 21, 2010 at 3:35 pm

    On 09/21/2010 11:20 AM, Heikki Linnakangas wrote:
    On 21/09/10 18:02, Tom Lane wrote:
    Peter Eisentraut<peter_e@gmx.net> 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 vote: Forget the whole thing.
    The folks who are more familiar with git than I seem to be pretty clear
    that we need to ignore all build products. I don't think that "ignore
    nothing" is going to work pleasantly at all. On reflection I realize
    that cvs ignore and git ignore are considerably different because they
    come into play at different times: cvs ignore really only matters while
    doing "cvs update" to pull in new code, while git ignore matters while
    you're constructing a commit. So you really do need git ignore to
    ignore all build products; otherwise you'll have lots of chatter in
    "git status".
    Agreed. It's not a big deal though, until now I've just always used
    "git status | less" and scrolled up to the beginning, ignoring the
    chatter.
    FWIW, the buildfarm's git mode does not rely on ignore files any more,
    unlike what we had for CVS. This came about after I followed up on a
    suggestion Robert made at pgCon to use "git clean".

    cheers

    andrew
  • Abhijit Menon-Sen at Sep 21, 2010 at 4:26 pm

    At 2010-09-21 11:02:30 -0400, tgl@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 I haven't tried to figure out
    how hard it would be to do that with the Postgres Makefiles, so it's
    just a thought, not a serious suggestion).

    -- ams
  • James Cloos at Oct 10, 2010 at 4:34 am
    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 dirty designation is important when using it in that
    fashion. But it helps to be able to run git add --all cleanly.

    I understand that other git users have similar experience.

    -JimC
    --
    James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
  • Tom Lane at Oct 10, 2010 at 4:42 am

    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 these sorts of things are
    dependent on one's personal work habits, choice of editor and patch
    tool, etc. So we're not ignoring them in the common project .gitignore
    files, but it's easy enough to install them in a private ignore file.

    regards, tom lane
  • Florian Weimer at Oct 11, 2010 at 7:28 am

    * 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 Weimer <fweimer@bfk.de>
    BFK edv-consulting GmbH http://www.bfk.de/
    Kriegsstraße 100 tel: +49-721-96201-1
    D-76133 Karlsruhe fax: +49-721-96201-99

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 21, '10 at 4:00a
activeOct 11, '10 at 7:28a
posts47
users11
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase