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@gmx.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@gmx.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.Bunce@pobox.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.Bunce@pobox.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@gmail.com> wrote:
On Thu, Jan 7, 2010 at 15:16, Tim Bunce <Tim.Bunce@pobox.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@gmail.com> wrote:
On Thu, Jan 7, 2010 at 15:16, Tim Bunce <Tim.Bunce@pobox.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@hagander.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@hagander.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@sss.pgh.pa.us> wrote:
Peter Eisentraut <peter_e@gmx.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@timbira.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@gmail.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@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.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@fetter.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@fetter.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@commandprompt.com> wrote:
Tom Lane escribió:
David Fetter <david@fetter.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.
