Re: Add .gitignore files to CVS?

I've a .git/info/exclude file I pulled from a link on the dev wiki.

Some of the changes I'm making create new files that ought to be added
to the excluded files. I can easily add them to my .git/info/exclude
file but it's much more work for me and others to spread those changes.

Is there any reason not to add .gitignore files into the repository?
They'll make no difference to those who don't use git, but be very
helpful to, and maintained by, those who do.

Tim.

On tor, 2010-01-07 at 22:16 +0000, Tim Bunce wrote:
> I've a .git/info/exclude file I pulled from a link on the dev wiki.
>
> Some of the changes I'm making create new files that ought to be added
> to the excluded files. I can easily add them to my .git/info/exclude
> file but it's much more work for me and others to spread those changes.
>
> Is there any reason not to add .gitignore files into the repository?
> They'll make no difference to those who don't use git, but be very
> helpful to, and maintained by, those who do.

I already find the .cvsignore files to be useless and an annoyance to
keep up to date (well, I basically ignore them and someone else cleans
up after me), but if you are thinking about
<http://wiki.postgresql.org/wiki/GitExclude>, which looks like an
outdated list of every single file that is built, then I think that is
going completely overboard. Why don't you just ignore every single file
by default and override it on a case-by-case basis? That would at least
give reliable results.

On Thursday 07 January 2010 23:32:27 Peter Eisentraut wrote:
> On tor, 2010-01-07 at 22:16 +0000, Tim Bunce wrote:
> > I've a .git/info/exclude file I pulled from a link on the dev wiki.
> >
> > Some of the changes I'm making create new files that ought to be added
> > to the excluded files. I can easily add them to my .git/info/exclude
> > file but it's much more work for me and others to spread those changes.
> >
> > Is there any reason not to add .gitignore files into the repository?
> > They'll make no difference to those who don't use git, but be very
> > helpful to, and maintained by, those who do.
>
> I already find the .cvsignore files to be useless and an annoyance to
> keep up to date (well, I basically ignore them and someone else cleans
> up after me), but if you are thinking about
> <http://wiki.postgresql.org/wiki/GitExclude>, which looks like an
> outdated list of every single file that is built, then I think that is
> going completely overboard. Why don't you just ignore every single file
> by default and override it on a case-by-case basis? That would at least
> give reliable results.
Because that way you forget new files in patches way much easier.

Andres

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On tor, 2010-01-07 at 22:16 +0000, Tim Bunce wrote:
>> Is there any reason not to add .gitignore files into the repository?

> I already find the .cvsignore files to be useless and an annoyance to
> keep up to date (well, I basically ignore them and someone else cleans
> up after me),

When/if we move off CVS, we should drop the .cvsignore files and insert
.gitignore (assuming that works the same way). I am not in favor of
expecting the core project to maintain support for non-core SCMs though.
Will we have .bzrignore and who knows what else in there too?

As Peter points out, the only way the things will get maintained is if
the complaints they suppress are in-the-face of somebody with commit
access to the core repo. I like quiet from my "cvs update"s, so I'm
willing to maintain .cvsignores, but I'm not willing to maintain
multiple copies of that information.

regards, tom lane

On Thu, Jan 07, 2010 at 05:45:08PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On tor, 2010-01-07 at 22:16 +0000, Tim Bunce wrote:
> >> Is there any reason not to add .gitignore files into the repository?
>
> > I already find the .cvsignore files to be useless and an annoyance to
> > keep up to date (well, I basically ignore them and someone else cleans
> > up after me),
>
> When/if we move off CVS, we should drop the .cvsignore files and insert
> .gitignore (assuming that works the same way). I am not in favor of
> expecting the core project to maintain support for non-core SCMs though.
> Will we have .bzrignore and who knows what else in there too?
>
> As Peter points out, the only way the things will get maintained is if
> the complaints they suppress are in-the-face of somebody with commit
> access to the core repo. I like quiet from my "cvs update"s, so I'm
> willing to maintain .cvsignores, but I'm not willing to maintain
> multiple copies of that information.

How about a "make gitignore" target that copies each .cvsignore file to
a .gitignore file and appends .gitignore to it?

That way git users can just do "make gitignore" to get working .gitignore
files without cluttering the repository. As a bonus they'll then have an
incentive to update the .cvsignore files.

Tim.

On Thu, Jan 7, 2010 at 15:16, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
> Is there any reason not to add .gitignore files into the repository?
> They'll make no difference to those who don't use git, but be very
> helpful to, and maintained by, those who do.

Since it seems we don't want them in CVS, maybe just add it to the git
mirror? I don't know that we want the git mirror to have
commits/files that CVS does not. *shrug* Thoughts people?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jan 07, 2010 at 04:44:49PM -0700, Alex Hunsaker wrote:
> On Thu, Jan 7, 2010 at 15:16, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
> > Is there any reason not to add .gitignore files into the repository?
> > They'll make no difference to those who don't use git, but be very
> > helpful to, and maintained by, those who do.
>
> Since it seems we don't want them in CVS, maybe just add it to the git
> mirror? I don't know that we want the git mirror to have
> commits/files that CVS does not. *shrug* Thoughts people?

...then you would have to add .gitignore to .cvsignore, lest cvs commit
complains about *that* ;-P

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLRvGvBcgs9XrR2kYRAoWbAJwNU6Zt5gfYiBipzNFPuZAnbLsgeACdGWac
0UegxgApq7SHGRwR++tt/sI=
=Iatz
-----END PGP SIGNATURE-----

On Fri, Jan 8, 2010 at 00:44, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
> On Thu, Jan 7, 2010 at 15:16, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
>> Is there any reason not to add .gitignore files into the repository?
>> They'll make no difference to those who don't use git, but be very
>> helpful to, and maintained by, those who do.
>
> Since it seems we don't want them in CVS, maybe just add it to the git
> mirror?  I don't know that we want the git mirror to have
> commits/files that CVS does not. *shrug*  Thoughts people?

Definite -1. We want the git repository to be (as much as possible)
identical to the CVS one.

You can always create your own branch with just the .gitignore files
and merge that into whatever you're working on :)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander escribió:
> On Fri, Jan 8, 2010 at 00:44, Alex Hunsaker <badalex(at)gmail(dot)com> wrote:
> > On Thu, Jan 7, 2010 at 15:16, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com> wrote:
> >> Is there any reason not to add .gitignore files into the repository?
> >> They'll make no difference to those who don't use git, but be very
> >> helpful to, and maintained by, those who do.
> >
> > Since it seems we don't want them in CVS, maybe just add it to the git
> > mirror?  I don't know that we want the git mirror to have
> > commits/files that CVS does not. *shrug*  Thoughts people?
>
> Definite -1. We want the git repository to be (as much as possible)
> identical to the CVS one.
>
> You can always create your own branch with just the .gitignore files
> and merge that into whatever you're working on :)

Do .gitignore files have the same format as .cvsignore? If that's the
case then it's simply a matter of a "find /source -name .cvsignore -exec
cp {} .gitignore \;" or similar, isn't it? Doesn't sound like something
anybody should sweat over.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

On Fri, Jan 8, 2010 at 02:03, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> You can always create your own branch with just the .gitignore files
> and merge that into whatever you're working on :)

The only thing annoying about that is if you generate diffs ala git
diff origin/master.. you get your .gitignore in it.

What I do is have a .gitignore that is gitignored. That way its not
committed, its on any branch i switch to or make and I don't
accidentally commit it.

On Friday 08 January 2010 17:38:15 Alex Hunsaker wrote:
> On Fri, Jan 8, 2010 at 02:03, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> > You can always create your own branch with just the .gitignore files
> > and merge that into whatever you're working on :)
>
> The only thing annoying about that is if you generate diffs ala git
> diff origin/master.. you get your .gitignore in it.
>
> What I do is have a .gitignore that is gitignored. That way its not
> committed, its on any branch i switch to or make and I don't
> accidentally commit it.
Thats what .git/info/excludes is for...

Andres

On Thu, Jan 7, 2010 at 5:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On tor, 2010-01-07 at 22:16 +0000, Tim Bunce wrote:
>>> Is there any reason not to add .gitignore files into the repository?
>
>> I already find the .cvsignore files to be useless and an annoyance to
>> keep up to date (well, I basically ignore them and someone else cleans
>> up after me),
>
> When/if we move off CVS, we should drop the .cvsignore files and insert
> .gitignore (assuming that works the same way).  I am not in favor of
> expecting the core project to maintain support for non-core SCMs though.
> Will we have .bzrignore and who knows what else in there too?
>
> As Peter points out, the only way the things will get maintained is if
> the complaints they suppress are in-the-face of somebody with commit
> access to the core repo.  I like quiet from my "cvs update"s, so I'm
> willing to maintain .cvsignores, but I'm not willing to maintain
> multiple copies of that information.

I would be willing to maintain .gitignore files, under the agreement
that if I should fail or cease to do so, and no one else wants to take
over, then they all get removed. Would that be acceptable?

...Robert

Robert Haas escreveu:
> I would be willing to maintain .gitignore files, under the agreement
> that if I should fail or cease to do so, and no one else wants to take
> over, then they all get removed. Would that be acceptable?
>
-1. I tend to agree with Tom and Peter. Why don't you use vpath builds when
using your favorite SCM? That way, we don't have trouble with auto-generated
files while getting your patch.

--
Euler Taveira de Oliveira
http://www.timbira.com/

On Fri, Jan 8, 2010 at 9:21 PM, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> wrote:
> Robert Haas escreveu:
>> I would be willing to maintain .gitignore files, under the agreement
>> that if I should fail or cease to do so, and no one else wants to take
>> over, then they all get removed.   Would that be acceptable?
>>
> -1. I tend to agree with Tom and Peter. Why don't you use vpath builds when
> using your favorite SCM? That way, we don't have trouble with auto-generated
> files while getting your patch.

Tom's stated position was that the only way this was going to happen
is if it regularly annoyed someone with access to the core repository.
I am, and I do.

Peter's position was that the excludes-list on the wiki was out of
date and useless, that he doesn't like .cvsignore files, and that he
lets other people clean up after him. I'm not disputing any of that;
at the same time, I am constantly ignored by the failure to have
proper .gitignore files, so I'm motivated to put in the work to clean
up after him and everyone else.

I don't find vpath builds to be convenient, so that is why I do not
use them regularly. I am not sure what you mean by "trouble with
auto-generated files when getting my patch".

The only downside I can see to allowing this to move forward is that
it will create some small amount of additional commit traffic as a
result of me updating the files. But I don't think it would be very
much - only a small percentage of our commits add new auto-generated
files.

Having said all that, I don't care to argue about it. It's not worth it.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Tom's stated position was that the only way this was going to happen
> is if it regularly annoyed someone with access to the core repository.
> I am, and I do.

Yeah. I don't see the harm in it if Robert (or some other git user)
will contract to maintain them. I know that I regularly forget to
deal with .cvsignore files until I see a cvs notice, so there's no
way that they'll be kept up to date without such feedback.

Probably eventually we'll be on git and this will be moot, but that
doesn't seem to be ready to happen.

regards, tom lane

On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote:
> Probably eventually we'll be on git and this will be moot, but that
> doesn't seem to be ready to happen.

What still needs to happen on this? Clearly this would be a post-8.5
(or whatever the new release number is) thing, but apart from that?

Cheers,
David (git! git! git! ;)
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

David Fetter <david(at)fetter(dot)org> writes:
> On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote:
>> Probably eventually we'll be on git and this will be moot, but that
>> doesn't seem to be ready to happen.

> What still needs to happen on this? Clearly this would be a post-8.5
> (or whatever the new release number is) thing, but apart from that?

AFAIR, we still weren't convinced that we had a 100% conversion method
(ie something that would preserve all the history) and there were still
questions about how to work with multi-branch patches most effectively.
I don't recall where the previous discussion died off exactly, but
it definitely wasn't at the "we're ready to do it" stage.

regards, tom lane

Tom Lane escribió:
> David Fetter <david(at)fetter(dot)org> writes:
> > On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote:
> >> Probably eventually we'll be on git and this will be moot, but that
> >> doesn't seem to be ready to happen.
>
> > What still needs to happen on this? Clearly this would be a post-8.5
> > (or whatever the new release number is) thing, but apart from that?
>
> AFAIR, we still weren't convinced that we had a 100% conversion method
> (ie something that would preserve all the history) and there were still
> questions about how to work with multi-branch patches most effectively.
> I don't recall where the previous discussion died off exactly, but
> it definitely wasn't at the "we're ready to do it" stage.

Somebody did a pull of all the tags, and some of them were missing files
and failed to build.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Sat, Jan 9, 2010 at 05:54, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> Tom Lane escribió:
>> David Fetter <david(at)fetter(dot)org> writes:
>> > On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote:
>> >> Probably eventually we'll be on git and this will be moot, but that
>> >> doesn't seem to be ready to happen.
>>
>> > What still needs to happen on this?  Clearly this would be a post-8.5
>> > (or whatever the new release number is) thing, but apart from that?
>>
>> AFAIR, we still weren't convinced that we had a 100% conversion method
>> (ie something that would preserve all the history) and there were still
>> questions about how to work with multi-branch patches most effectively.
>> I don't recall where the previous discussion died off exactly, but
>> it definitely wasn't at the "we're ready to do it" stage.
>
> Somebody did a pull of all the tags, and some of them were missing files
> and failed to build.

That was from the current git mirror.

To re-itarate yet again, what I believe has been said many times before:

There are two ways to get from cvs to git.

The first one is reliable (at least from what I've heard). But it only
supports one-off migrations. It doesn't support incremental changes.
It was confused by some things that were plain broken in our cvs
repository way back (this happens with cvs, as we all know), but AFAIK
they have been fixed.

The second one supports incremental changes. And has issues with
back-branches. This is the one we are using.

If/when we are moving the main repository, we should use the first
one. Yes, this will invalidate all current git clones out there, but
that's a one-time cost. Will there be issues? Possibly. But we're
*never* going to get something that's *guaranteed* 100% safe, not when
going from something like CVS...

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On fre, 2010-01-08 at 12:04 -0300, Alvaro Herrera wrote:
> Do .gitignore files have the same format as .cvsignore? If that's the
> case then it's simply a matter of a "find /source -name .cvsignore
> -exec
> cp {} .gitignore \;" or similar, isn't it? Doesn't sound like
> something
> anybody should sweat over.

The format is the same, but while cvsignore files currently list a few
dozen files, the proposed gitignore would list all files that are ever
build anywhere.

On fre, 2010-01-08 at 20:03 -0800, David Fetter wrote:
> On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote:
> > Probably eventually we'll be on git and this will be moot, but that
> > doesn't seem to be ready to happen.
>
> What still needs to happen on this? Clearly this would be a post-8.5
> (or whatever the new release number is) thing, but apart from that?

Probably someone to actually track the open items that are mentioned
every time this discussion happens.

On Sat, Jan 09, 2010 at 12:47:00PM +0100, Magnus Hagander wrote:
> But we're *never* going to get something that's *guaranteed* 100%
> safe,

You can end the sentence right there. *Everything* has a strictly
positive probability of catastrophic failure.

> not when going from something like CVS...

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> If/when we are moving the main repository, we should use the first
> one. Yes, this will invalidate all current git clones out there, but
> that's a one-time cost. Will there be issues? Possibly. But we're
> *never* going to get something that's *guaranteed* 100% safe, not when
> going from something like CVS...

Alvaro already mentioned the success criterion that we agreed to:
be able to pull all of the past release tags from the repository
and get something that matches the actual release tarballs (perhaps
with an exception for $PostgreSQL$ tags and such). Surely the process
can be tested in advance.

regards, tom lane

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> On fre, 2010-01-08 at 12:04 -0300, Alvaro Herrera wrote:
>> Do .gitignore files have the same format as .cvsignore?

> The format is the same, but while cvsignore files currently list a few
> dozen files, the proposed gitignore would list all files that are ever
> build anywhere.

The charter of the .cvsignore files is to ignore files that are not in
the repository but are nonetheless left behind after "make distclean".
Any git-oriented replacement should behave the same IMO.

regards, tom lane

On Sat, Jan 9, 2010 at 17:32, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> If/when we are moving the main repository, we should use the first
>> one. Yes, this will invalidate all current git clones out there, but
>> that's a one-time cost. Will there be issues? Possibly. But we're
>> *never* going to get something that's *guaranteed* 100% safe, not when
>> going from something like CVS...
>
> Alvaro already mentioned the success criterion that we agreed to:
> be able to pull all of the past release tags from the repository
> and get something that matches the actual release tarballs (perhaps
> with an exception for $PostgreSQL$ tags and such).  Surely the process
> can be tested in advance.

If that's the only remaining obstacle, I'm willing to work up some
test scripts around that. But I'm not going to do that if it's going
to fall over on something else as well, because it'll be a nontrivial
amount of work to test ir properly :-)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On lör, 2010-01-09 at 12:00 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > On fre, 2010-01-08 at 12:04 -0300, Alvaro Herrera wrote:
> >> Do .gitignore files have the same format as .cvsignore?
>
> > The format is the same, but while cvsignore files currently list a few
> > dozen files, the proposed gitignore would list all files that are ever
> > build anywhere.
>
> The charter of the .cvsignore files is to ignore files that are not in
> the repository but are nonetheless left behind after "make distclean".
> Any git-oriented replacement should behave the same IMO.

Then it would be trivial, but that is not what is being proposed.

* Magnus Hagander <magnus(at)hagander(dot)net> [100109 12:03]:

> If that's the only remaining obstacle, I'm willing to work up some
> test scripts around that. But I'm not going to do that if it's going
> to fall over on something else as well, because it'll be a nontrivial
> amount of work to test ir properly :-)

It's already been done. It was not a lot of work (just processor time).
It's even already been posted to -hackers, including what the
differences were (i.e. which $Tags$ differed, and where, and where the
CVS history had been hacked by hand).

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

On Sat, Jan 9, 2010 at 18:33, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> * Magnus Hagander <magnus(at)hagander(dot)net> [100109 12:03]:
>
>> If that's the only remaining obstacle, I'm willing to work up some
>> test scripts around that. But I'm not going to do that if it's going
>> to fall over on something else as well, because it'll be a nontrivial
>> amount of work to test ir properly :-)
>
> It's already been done.  It was not a lot of work (just processor time).
> It's even already been posted to -hackers, including what the
> differences were (i.e. which $Tags$ differed, and where, and where the
> CVS history had been hacked by hand).

Do you still have the scripts?

IIRC we fixed at least some of the brokenness in the CVS repo?

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sat, Jan 9, 2010 at 18:33, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
>> It's already been done. It was not a lot of work (just processor time).
>> It's even already been posted to -hackers, including what the
>> differences were (i.e. which $Tags$ differed, and where, and where the
>> CVS history had been hacked by hand).

> Do you still have the scripts?

> IIRC we fixed at least some of the brokenness in the CVS repo?

I think we had *not*, but clearly that would be an appropriate next step
to take (and then retry the import experiment).

regards, tom lane

On Sat, Jan 09, 2010 at 12:47:00PM +0100, Magnus Hagander wrote:
> On Sat, Jan 9, 2010 at 05:54, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> > Tom Lane escribió:
> >> David Fetter <david(at)fetter(dot)org> writes:
> >> > On Fri, Jan 08, 2010 at 10:35:24PM -0500, Tom Lane wrote:
> >> >> Probably eventually we'll be on git and this will be moot, but that
> >> >> doesn't seem to be ready to happen.
> >>
> >> > What still needs to happen on this?  Clearly this would be a post-8.5
> >> > (or whatever the new release number is) thing, but apart from that?
> >>
> >> AFAIR, we still weren't convinced that we had a 100% conversion method
> >> (ie something that would preserve all the history) and there were still
> >> questions about how to work with multi-branch patches most effectively.
> >> I don't recall where the previous discussion died off exactly, but
> >> it definitely wasn't at the "we're ready to do it" stage.
> >
> > Somebody did a pull of all the tags, and some of them were missing files
> > and failed to build.
>
> That was from the current git mirror.
>
> To re-itarate yet again, what I believe has been said many times before:
>
> There are two ways to get from cvs to git.
>
> The first one is reliable (at least from what I've heard). But it only
> supports one-off migrations. It doesn't support incremental changes.
> It was confused by some things that were plain broken in our cvs
> repository way back (this happens with cvs, as we all know), but AFAIK
> they have been fixed.

As a git user who has now done a number of CVS->git migrations over the
past few years, I also found that the various tools to do the
conversion do have their own issues (such as cvsps) which can lead to
incorrect history in some corner cases. Unfortunately, in any big
repo with a lot of history, you do tend to find you trip up on them
in a few places.

My experience was that the CVS->SVN conversion tended to be rather
more reliable and accurate. As a result, going GIT->SVN->git can
give a much better history. At least in my experience.

Regards,
Roger

--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.

On Sat, Jan 9, 2010 at 12:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On fre, 2010-01-08 at 12:04 -0300, Alvaro Herrera wrote:
>>> Do .gitignore files have the same format as .cvsignore?
>
>> The format is the same, but while cvsignore files currently list a few
>> dozen files, the proposed gitignore would list all files that are ever
>> build anywhere.
>
> The charter of the .cvsignore files is to ignore files that are not in
> the repository but are nonetheless left behind after "make distclean".
> Any git-oriented replacement should behave the same IMO.

Oh. Never mind. That doesn't seem useful enough to be worth spending
time on. What I want is to ignore all of the build products, so that
when I do 'git status' in my working tree, I only see the the files
I've actually added/changed. Now that you mention it, I think I had
the same complaint about the .cvsignore files back when I was using
CVS. It seems like an odd charter.

...Robert

Robert Haas wrote:
> On Sat, Jan 9, 2010 at 12:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>
>>> On fre, 2010-01-08 at 12:04 -0300, Alvaro Herrera wrote:
>>>
>>>> Do .gitignore files have the same format as .cvsignore?
>>>>
>>> The format is the same, but while cvsignore files currently list a few
>>> dozen files, the proposed gitignore would list all files that are ever
>>> build anywhere.
>>>
>> The charter of the .cvsignore files is to ignore files that are not in
>> the repository but are nonetheless left behind after "make distclean".
>> Any git-oriented replacement should behave the same IMO.
>>
>
> Oh. Never mind. That doesn't seem useful enough to be worth spending
> time on. What I want is to ignore all of the build products, so that
> when I do 'git status' in my working tree, I only see the the files
> I've actually added/changed. Now that you mention it, I think I had
> the same complaint about the .cvsignore files back when I was using
> CVS. It seems like an odd charter.
>
>

Use a vpath build, and you'll keep those artifacts out of your source tree.

cheers

andrew

On Sat, Jan 9, 2010 at 5:18 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Robert Haas wrote:
>> On Sat, Jan 9, 2010 at 12:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>>>> On fre, 2010-01-08 at 12:04 -0300, Alvaro Herrera wrote:
>>>>> Do .gitignore files have the same format as .cvsignore?
>>>> The format is the same, but while cvsignore files currently list a few
>>>> dozen files, the proposed gitignore would list all files that are ever
>>>> build anywhere.
>>>
>>> The charter of the .cvsignore files is to ignore files that are not in
>>> the repository but are nonetheless left behind after "make distclean".
>>> Any git-oriented replacement should behave the same IMO.
>>>
>>
>> Oh.  Never mind.  That doesn't seem useful enough to be worth spending
>> time on.  What I want is to ignore all of the build products, so that
>> when I do 'git status' in my working tree, I only see the the files
>> I've actually added/changed.  Now that you mention it, I think I had
>> the same complaint about the .cvsignore files back when I was using
>> CVS.  It seems like an odd charter.
>>
> Use a vpath build, and you'll keep those artifacts out of your source tree.

I suppose that's one answer, but of what use is it to ignore only the
'make distclean' leftovers?

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sat, Jan 9, 2010 at 5:18 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> Robert Haas wrote:
>>> What I want is to ignore all of the build products

>> Use a vpath build, and you'll keep those artifacts out of your source tree.

> I suppose that's one answer, but of what use is it to ignore only the
> 'make distclean' leftovers?

Well, it fits my workflow, which is make distclean -> cvs update ->
fresh build. If you want to update without cleaning the build tree,
using a separate build tree seems like a much better answer.

regards, tom lane

On lör, 2010-01-09 at 17:19 -0500, Robert Haas wrote:
> >> Oh. Never mind. That doesn't seem useful enough to be worth spending
> >> time on. What I want is to ignore all of the build products, so that
> >> when I do 'git status' in my working tree, I only see the the files
> >> I've actually added/changed. Now that you mention it, I think I had
> >> the same complaint about the .cvsignore files back when I was using
> >> CVS. It seems like an odd charter.
> >>
> > Use a vpath build, and you'll keep those artifacts out of your source tree.
>
> I suppose that's one answer, but of what use is it to ignore only the
> 'make distclean' leftovers?

That charter was established before make maintainer-clean was invented.

On Sat, Jan 9, 2010 at 5:44 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Sat, Jan 9, 2010 at 5:18 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>> Robert Haas wrote:
>>>> What I want is to ignore all of the build products
>
>>> Use a vpath build, and you'll keep those artifacts out of your source tree.
>
>> I suppose that's one answer, but of what use is it to ignore only the
>> 'make distclean' leftovers?
>
> Well, it fits my workflow, which is make distclean -> cvs update ->
> fresh build.  If you want to update without cleaning the build tree,
> using a separate build tree seems like a much better answer.

Oh, I see. With git, I clean the tree with "git clean -dfx" rather
than "make distclean". That just blows away all the files that aren't
in the repository. I find that faster and more reliable than "make
distclean", although of course you have to be careful not to be leave
anything in the tree that you were planning to hold on to...

...Robert

On lör, 2010-01-09 at 17:12 -0500, Robert Haas wrote:
> Oh. Never mind. That doesn't seem useful enough to be worth spending
> time on. What I want is to ignore all of the build products, so that
> when I do 'git status' in my working tree, I only see the the files
> I've actually added/changed.

Shouldn't it be possible to just build the master branch once and then
take the result of git status to produce the list of files to be
ignored? That should reduce the maintenance effort.

On Sat, Jan 9, 2010 at 5:53 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On lör, 2010-01-09 at 17:12 -0500, Robert Haas wrote:
>> Oh.  Never mind.  That doesn't seem useful enough to be worth spending
>> time on.  What I want is to ignore all of the build products, so that
>> when I do 'git status' in my working tree, I only see the the files
>> I've actually added/changed.
>
> Shouldn't it be possible to just build the master branch once and then
> take the result of git status to produce the list of files to be
> ignored?  That should reduce the maintenance effort.

Oh, for sure. That's what I would do, although I would say we should
ignore *.o in the relevant directories rather than listing out the
individual files. But if Tom only wants the things that remain after
'make distclean' to be ignored, then it's not actually going to solve
any problem that I have, because, as mentioned upthread, I use
'git-clean -dfx' to clean my tree. What I'm interested in is being
able to run 'git status' on a tree in which I've run a build without
getting a lot of extra output, and that will require ignoring all the
build products.

...Robert

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> ... What I'm interested in is being
> able to run 'git status' on a tree in which I've run a build without
> getting a lot of extra output, and that will require ignoring all the
> build products.

I'm fairly hesitant to set up ignore files that list *all* the build
products (or even all the non-.o ones) because of the probability of
error --- in particular, the likelihood that this would mask an omission
in a "make clean" rule. The current charter for .cvsignore is
relatively safe and low-maintenance because there are so few built files
that are supposed to remain around in a distribution tree. What you're
talking about would require a great deal more maintenance effort, and
I don't see the point compared to using a VPATH build.

regards, tom lane

On Sat, Jan 9, 2010 at 6:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> ... What I'm interested in is being
>> able to run 'git status' on a tree in which I've run a build without
>> getting a lot of extra output, and that will require ignoring all the
>> build products.
>
> I'm fairly hesitant to set up ignore files that list *all* the build
> products (or even all the non-.o ones) because of the probability of
> error --- in particular, the likelihood that this would mask an omission
> in a "make clean" rule.  The current charter for .cvsignore is
> relatively safe and low-maintenance because there are so few built files
> that are supposed to remain around in a distribution tree.  What you're
> talking about would require a great deal more maintenance effort, and
> I don't see the point compared to using a VPATH build.

That seems to be a common POV, so I think we should just let it go.

...Robert

Peter Eisentraut wrote:
> Probably someone to actually track the open items that are mentioned
> every time this discussion happens.
>

http://wiki.postgresql.org/wiki/Switching_PostgreSQL_from_CVS_to_Git now
has what I believe the state of the world to be in this area.

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com

Hi,

Another occasion to show ignorance, I couldn't resist!

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> What you're
> talking about would require a great deal more maintenance effort, and
> I don't see the point compared to using a VPATH build.

I've discovered VPATH builds pretty recently, in the context of
packaging extensions. The concept is simple but it could be helpful if
spelled in simple terms: VPATH is about finding the sources.

So you build wherever you want without messing your checkout. But you
build from the target directory, telling in VPATH where the sources are.

HTH, regards,
--
dim

* Magnus Hagander <magnus(at)hagander(dot)net> [100109 13:05]:
> On Sat, Jan 9, 2010 at 18:33, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> > * Magnus Hagander <magnus(at)hagander(dot)net> [100109 12:03]:
> >
> >> If that's the only remaining obstacle, I'm willing to work up some
> >> test scripts around that. But I'm not going to do that if it's going
> >> to fall over on something else as well, because it'll be a nontrivial
> >> amount of work to test ir properly :-)
> >
> > It's already been done.  It was not a lot of work (just processor time).
> > It's even already been posted to -hackers, including what the
> > differences were (i.e. which $Tags$ differed, and where, and where the
> > CVS history had been hacked by hand).
>
> Do you still have the scripts?

Well, I have a screen running yet with bash history showing most of the
commands...

Basically, with a local $CVSROOT, import every tag/release/branch you want
into git as a tree:
for b in $(cat ../tags.txt); do echo $b; rm -Rf * .git/index; cvs export -kk -r $b -d ./ pgsql > /dev/null && git add --all && git tag -f cvs-tag-$b $(git write-tree); done

And then, it's a simple matter of letting git diff the git ref with the corespnding CVS export tree them:
for b in $(cat ../tags.txt); do echo $b; git diff $b cvs-tag-$b > /tmp/pg-parsecvs-$b.diff; done

a.

--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.

Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> What I'm interested in is being able to run 'git status' on a tree
> in which I've run a build without getting a lot of extra output,
> and that will require ignoring all the build products.

If you prefer to keep it all in one directory tree, something like
the following would work on Linux. (The first of the two statements
would probably need a slight tweak to work on other *nix, but I'm
not sure of the best format.)

echo '# Globally ignore common build product patterns.

*.[oa]
*.so
*.so.*

# Ignore specific files.
' > .gitignore
git status | grep '^#[^ ]' | sed -e 's/#\t//' \
-e '/^[^\/][^\/]*$/ s/^/\//' >> .gitignore

If you run that right after branching and building, you should be
set. It produces the attached for me, which seems to work. For me,
at least. On kubuntu.

If we included and maintained the attached file in the repository,
it'd save running the above. That seems reasonable to me, but I
don't care enough to argue over it.

-Kevin

I wrote:
> git status | grep '^#[^ ]' | sed -e 's/#\t//' \
> -e '/^[^\/][^\/]*$/ s/^/\//' >> .gitignore

I guess that part can be simplified to:

git status | grep '^#[^ ]' | sed -e 's/#\t/\//' >> .gitignore

-Kevin

badalex(at)gmail(dot)com (Alex Hunsaker) writes:
> On Fri, Jan 8, 2010 at 02:03, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>> You can always create your own branch with just the .gitignore files
>> and merge that into whatever you're working on :)
>
> The only thing annoying about that is if you generate diffs ala git
> diff origin/master.. you get your .gitignore in it.
>
> What I do is have a .gitignore that is gitignored. That way its not
> committed, its on any branch i switch to or make and I don't
> accidentally commit it.

I'd put that in $GITHOME/.git/info/exclude

That's specifically what that file's for...
--
output = reverse("moc.liamg" "@" "enworbbc")
http://www3.sympatico.ca/cbbrowne/slony.html
DSK: STAN.K; ML EXIT -- FILE NOT FOUND