Aidan Van Dyk wrote:
* Florian G. Pflug <[EMAIL PROTECTED]> [070430 08:58]:
It seems as if git pulls all revisions of all files during the pull -
which it shouldn't do as far as I understand things - it should only
pull those objects referenced by some head, no?
Git pulls full history to a c
* Florian G. Pflug <[EMAIL PROTECTED]> [070430 08:58]:
> It seems as if git pulls all revisions of all files during the pull -
> which it shouldn't do as far as I understand things - it should only
> pull those objects referenced by some head, no?
Git pulls full history to a common ancestor on t
Martin Langhoff wrote:
So - if you are committed to providing your gateway long term to
Florian, I'm happy to drop my gateway in favour of yours.
(Florian, before basing your code on either you should get a checkout of
Aidan's and mine and check that the tips of the branches you are working
on
Jim C. Nasby wrote:
> Not bad... took you 40 lines to answer my question. Let's see if I can
> beat that...
Sure - it'll be 1 line when it's wrapped in a shell script. And then
we'll be even.
> I understand the argument about metadata and all, and largely agree with
> it. But on the other hand I
Jim C. Nasby wrote:
> Then how do you tell what version a file is if it's outside of a
> checkout?
It's trivial for git to answer that - the file will either be pristine,
and then we can just scan for the matching SHA1, or modified, and we can
scan (taking a weee bit more time) which are the "clos
Hi
Jim C. Nasby wrote:
I understand the argument about metadata and all, and largely agree with
it. But on the other hand I think a version identifier is a critical
piece of information; it's just as critical as the file name when it
comes to identifying the information contained in the file.
Hi,
Alvaro Herrera wrote:
Which is not always what happens in reality. Consider for example that
we borrowed some files from NetBSD, OpenBSD, Tcl, zic and others. It
would be nice to know exactly at what point we borrowed the file, so we
can go to the upstream repo and check if there's any bug
On Thu, Apr 19, 2007 at 10:07:08AM +1200, Martin Langhoff wrote:
> Jim C. Nasby wrote:
> > Then how do you tell what version a file is if it's outside of a
> > checkout?
>
> It's trivial for git to answer that - the file will either be pristine,
> and then we can just scan for the matching SHA1, o
Aidan Van Dyk wrote:
> * Aidan Van Dyk <[EMAIL PROTECTED]> [070418 15:03]:
>
> > > Then how do you tell what version a file is if it's outside of a
> > > checkout?
> >
> > That's what all the fun is about ;-) Some would say that "labelling" the
> > file is the job of the release processes. Othe
* Aidan Van Dyk <[EMAIL PROTECTED]> [070418 15:03]:
> > Then how do you tell what version a file is if it's outside of a
> > checkout?
>
> That's what all the fun is about ;-) Some would say that "labelling" the
> file is the job of the release processes. Others say it's the job of
> the SCM sy
* Jim C. Nasby <[EMAIL PROTECTED]> [070418 14:39]:
> On Wed, Apr 18, 2007 at 06:39:34PM +1200, Martin Langhoff wrote:
> > Keyword expansions are generally bad because SCM tools should track
> > _content_ - and keyword expansions _modify_ it to add metadata that is
> > somewhat redundant, obtainable
On Wed, Apr 18, 2007 at 06:39:34PM +1200, Martin Langhoff wrote:
> Keyword expansions are generally bad because SCM tools should track
> _content_ - and keyword expansions _modify_ it to add metadata that is
> somewhat redundant, obtainable in other ways, and should just not be in
> the middle of t
Tom Lane wrote:
> Um ... why do either of you feel there's an issue there?
>
> We switched over to $PostgreSQL$ a few years ago specifically to avoid
> creating merge problems for downstream repositories. If there are any
> other keyword expansions left in the source text I'd vote to remove
> the
Tom Lane wrote:
> Martin Langhoff <[EMAIL PROTECTED]> writes:
> > Aidan Van Dyk wrote:
> >> And remember the warning I gave that my conversion is *not* a direct CVS
> >> import - I intentionally *unexpand* all Keywords before stuffing them
> >> into GIT so that merging and branching can ignore all
* Tom Lane <[EMAIL PROTECTED]> [070418 01:33]:
> Um ... why do either of you feel there's an issue there?
>
> We switched over to $PostgreSQL$ a few years ago specifically to avoid
> creating merge problems for downstream repositories. If there are any
> other keyword expansions left in the sou
Martin Langhoff <[EMAIL PROTECTED]> writes:
> Aidan Van Dyk wrote:
>> And remember the warning I gave that my conversion is *not* a direct CVS
>> import - I intentionally *unexpand* all Keywords before stuffing them
>> into GIT so that merging and branching can ignore all the Keyword
>> conflicts..
* Florian G. Pflug <[EMAIL PROTECTED]> [070417 20:30]:
> >So - if you are committed to providing your gateway long term to
> >Florian, I'm happy to drop my gateway in favour of yours.
>
> There seem to be other people than me who are interested in a git
> mirror. Maybe we could declare one of tho
Aidan Van Dyk wrote:
> I'm an unknown here, I know - I've used PostgreSQL for years, but only
> recently started following the development community... And at this
I'm probably unknown here as well. Hi everyone ;-)
> And remember the warning I gave that my conversion is *not* a direct CVS
> impo
Martin Langhoff wrote:
Aidan Van Dyk wrote:
And remember the warning I gave that my conversion is *not* a direct CVS
import - I intentionally *unexpand* all Keywords before stuffing them
into GIT so that merging and branching can ignore all the Keyword
conflicts...
My import is unexpanding th
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> I have my CVS->GIT conversion running hourly from the anon-rsync of the
> cvsroot. I don't know the specifics of the PostgreSQL rsync/mirror
> setup, so I may be pulling it more frequently than it's actually
> published, but until I hear from someone tha
* Martin Langhoff <[EMAIL PROTECTED]> [070417 17:32]:
> > Having a git mirror of the pgsql CVS would be great.
> > BTW, I've just check out repo.or.cz, and noticed that there is already a
> > git mirror of the pgsql CVS: http://repo.or.cz/w/PostgreSQL.git
>
> Yes, I've seen it, but I don't know t
Florian G. Pflug wrote:
> Cool - I'm new to git, so I really appreciate any help that I can get.
Great - I am a SoC mentor for 2 other projects (git and moodle) so I've
got some time set aside for SoC stuff. You might as well take advantage
of it :-)
>> For the kind of work you'll be doing (writi
Florian G. Pflug wrote:
>> Initially, I'll post it on http://git.catalyst.net.nz/ and I can run a
>> daily import for you - once that's in place you can probably get a repo
>> with your work on http://repo.or.cz/
Ok - you can now clone from http://git.catalyst.net.nz/postgresql.git
viewable from h
Chris Browne wrote:
This strikes me as being a really super thing, having both Subversion
and Git repositories publicly available that are tracking the
PostgreSQL sources.
Stepping back to the SCM discussion, people were interested in finding
out what merits there were in having these sorts of S
Tom Lane wrote:
It shouldn't be a big problem, assuming the checkout preserves the file
dates --- they'll look older than the source files and so a rebuild will
happen anyway in such a checkout.
Actually this is a problem with at least SVN. A "svn export" will
create files with the original
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> Now, on my hand-crafted GIT repo - you see them in and out now with
> Tom's commits. But any *real* conversion tracking the *actual* RCS cvs
> states should have them checked out from 1999 to now in the state they
> were from vadim's last changes, and To
* Tom Lane <[EMAIL PROTECTED]> [070416 21:11]:
> I wrote:
> > So there's no way, apparently, to fix the state of these files through
> > the "front door".
>
> I take that back: the right sequence involving a "cvs update" got me
> into a state where it thought the files were "locally modified", and
Andrew Dunstan wrote:
> Tom Lane wrote:
> >So there's no way, apparently, to fix the state of these files through
> >the "front door". Shall we try the proposed idea of hand-moving the
> >files out of the Attic subdirectory, whereupon they should appear live
> >and we can cvs remove them again?
Tom Lane wrote:
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
* Tom Lane <[EMAIL PROTECTED]> [070416 19:03]:
I like the idea of re-adding and then re-removing the files on HEAD.
Does anyone think that poses any real risk?
No - it even fixed the "hand moved" test I had done tryi
I wrote:
> So there's no way, apparently, to fix the state of these files through
> the "front door".
I take that back: the right sequence involving a "cvs update" got me
into a state where it thought the files were "locally modified", and
then I could commit and "cvs remove" and commit again. So
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> * Tom Lane <[EMAIL PROTECTED]> [070416 19:03]:
>> I like the idea of re-adding and then re-removing the files on HEAD.
>> Does anyone think that poses any real risk?
> No - it even fixed the "hand moved" test I had done trying to create an
> Attic with,
* Tom Lane <[EMAIL PROTECTED]> [070416 19:03]:
> Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> > Would anyone know if these were "hand moved" to Attic?
>
> Seems unlikely, since there's a commit log entry for the removal. But
> this all happened seven-plus years ago and I'm sure there's an old CVS
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> Would anyone know if these were "hand moved" to Attic?
Seems unlikely, since there's a commit log entry for the removal. But
this all happened seven-plus years ago and I'm sure there's an old CVS
bug involved *somewhere*.
I like the idea of re-adding a
* Florian G. Pflug <[EMAIL PROTECTED]> [070416 16:16]:
> >I think this is a corner case that CVS handles in a particular way and
> >the tools people are using to read the repository handle in a different
> >way. Which would be a bug in those tools, since CVS's interpretation
> >must be right by d
[EMAIL PROTECTED] (Aidan Van Dyk) writes:
> I've "diffed" a CVS checkout and a git checkout, and the are *almost*
> identical. Almost, because it seems like my git repository currently has 3
> files that a cvs checkout doesn't:
> backend/parser/gram.c |12088 ++
[EMAIL PROTECTED] ("Florian G. Pflug") writes:
> Martin Langhoff wrote:
>> Hi Florian,
>> I am right now running an rsync of the Pg CVS repo to my work
>> machine to
>> get a git import underway. I'm rather keen on seeing your cool PITR Pg
>> project go well and I have some git+cvs fu I can apply h
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
These files are generated (from gram.y, pgc.l and preproc.y
respectievly) and are not present in the CVS repo, though I think they
have been at some point.
It's strange that other generated files (that have also been in the repo
in th
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> These files are generated (from gram.y, pgc.l and preproc.y
> respectievly) and are not present in the CVS repo, though I think they
> have been at some point.
> It's strange that other generated files (that have also been in the repo
> in the past) lik
Aidan Van Dyk wrote:
> I've "diffed" a CVS checkout and a git checkout, and the are *almost*
> identical. Almost, because it seems like my git repository currently has 3
> files that a cvs checkout doesn't:
> backend/parser/gram.c |12088 +++
> interfaces/ecpg
Aidan Van Dyk wrote:
Martin Langhoff wrote:
Well, now that more than one of us are working with git on PostgreSQL...
I've had a repo conversion running for a while... I've only got it to what
I consider "stable" last week:
http://repo.or.cz/w/PostgreSQL.git
git://repo.or.cz/PostgreSQL.g
Martin Langhoff wrote:
Hi Florian,
I am right now running an rsync of the Pg CVS repo to my work machine to
get a git import underway. I'm rather keen on seeing your cool PITR Pg
project go well and I have some git+cvs fu I can apply here (being one
of the git-cvsimport maintainers) ;-)
Cool -
* Aidan Van Dyk <[EMAIL PROTECTED]> [070416 14:08]:
> Note that this is a "special" conversion - I intentionally "unmunge" all the
> $PostgreSQL$ tags in this repo.
Blah - and I just noticed that I actually "missed" the $PostgreSQL$
(although I did catch the Date/Modified/From/etc)...
> I hat
Martin Langhoff wrote:
> Hi Florian,
>
> I am right now running an rsync of the Pg CVS repo to my work machine to
> get a git import underway. I'm rather keen on seeing your cool PITR Pg
> project go well and I have some git+cvs fu I can apply here (being one
> of the git-cvsimport maintainers) ;
Hi Florian,
I am right now running an rsync of the Pg CVS repo to my work machine to
get a git import underway. I'm rather keen on seeing your cool PITR Pg
project go well and I have some git+cvs fu I can apply here (being one
of the git-cvsimport maintainers) ;-)
For the kind of work you'll be d
44 matches
Mail list logo
