Thread: 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 HaganderMe: 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 HaganderMe: 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@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
Magnus Hagander <magnus@hagander.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@gmx.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@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.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 HaganderMe: 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@gmx.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@hagander.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@highrise.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@highrise.ca> wrote: > * Magnus Hagander <magnus@hagander.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 HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Sat, Jan 9, 2010 at 18:33, Aidan Van Dyk <aidan@highrise.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@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. 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@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.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@sss.pgh.pa.us> wrote: > >> Peter Eisentraut <peter_e@gmx.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@dunslane.net> wrote: > Robert Haas wrote: >> On Sat, Jan 9, 2010 at 12:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Peter Eisentraut <peter_e@gmx.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@gmail.com> writes:
> On Sat, Jan 9, 2010 at 5:18 PM, Andrew Dunstan <andrew@dunslane.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Sat, Jan 9, 2010 at 5:18 PM, Andrew Dunstan <andrew@dunslane.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@gmx.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@gmail.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@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.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@2ndQuadrant.com www.2ndQuadrant.com
Hi, Another occasion to show ignorance, I couldn't resist! Tom Lane <tgl@sss.pgh.pa.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@hagander.net> [100109 13:05]: > On Sat, Jan 9, 2010 at 18:33, Aidan Van Dyk <aidan@highrise.ca> wrote: > > * Magnus Hagander <magnus@hagander.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@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Robert Haas <robertmhaas@gmail.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
Attachment
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@gmail.com (Alex Hunsaker) writes:
> 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.
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