Front page | perl.perl5.porters |
Postings from February 2007
Re: git repository
From:
Sam Vilain
Date:
February 7, 2007 11:31
Subject:
Re: git repository
Message ID:
45CA28D9.1050402@vilain.net
Gerard Goossen wrote:
> Cool, I am currently using git to keep track of bleadperl and my branch, but I
> don't have the history, and my method of importing new changes from
> bleadperl is horrible (I often end up doing a rsync to just get all the
> changes).
> Can I get a clone of the repository? I know brances will be rebased etc,
> but it is far far better then what I have now.
> I tried:
>
> cg-clone git://git.catalyst.net.nz/public/perl.git#restorical
>
> but it only gave:
>
> defaulting to local storage area
> Fetching pack (head and objects)...
> fatal: unexpected EOF
> cg-fetch: fetching pack failed
Sorry, s{public/}{} on the URL. My mistake.
Of course it's ancient history :) Stops at about 5.003_07
In theory the "p4-perl" branch tracks blead. But, I noticed that after
about 30077 it broke, that's my next thing to look at. I haven't got it
automatically tracking upstream changes yet, and wasn't really planning
on it until I've got the metadata problem sorted.
I can probably make one that does automatically track recent changes,
but at this point the history will be flat, so a "blame" will normally
stop when it hits integrate changes.
Anyway, like I said, be prepared for 30,000+ commit rebasing, and be
warned that "git-upload-pack" doesn't implement binary search yet.
Sam.
>
>
> Gerard Goossen.
>
>
> On Tue, Feb 06, 2007 at 09:35:58PM +1300, Sam Vilain wrote:
>> Nicholas Clark wrote:
>>> There's a lot of things that predate the current maintainers, and many lines
>>> of code that are the (in)famous change 1
>>>
>>> Change 1 by mbeattie@localhost on 1997/03/28 13:17:33
>>>
>>> Perl 5.003 check-in
>>>
>>> http://public.activestate.com/cgi-bin/perlbrowse?show_patch=Show+Patch&patch_num=1
>> Well, the history at
>>
>> http://git.catalyst.net.nz/gitweb?p=perl.git;a=shortlog;h=restorical
>>
>> Doesn't suffer from that problem.
>>
>> It's far from complete - there were several old perl releases that
>> weren't available on history.perl.org, and I didn't have the old RCS
>> files that were originally used to maintain the code for more fine
>> grained conversion of the early perls. Some of the releases didn't ship
>> with per-file change comments, so they become just one revision. Also,
>> some of the messages in the perl5-porters referred to by Chip's pumpking
>> era don't seem to be in the archives, which is a bit of a shame because
>> the history is much more useful when you get a bit of a story with each
>> commit message. Although that's not technically in the history of the
>> Perforce repository, it might be good to see which of those changes were
>> merged.
>>
>> I'm currently working on grafting the Perforce history on top of the
>> point where it most cleanly fits, ie the 5.003 release. You'll see
>> various branches in that repository that capture some of this effort.
>>
>> In case it is not clear MOST OF THE BRANCHES IN THAT REPOSITORY WILL BE
>> REBASED - DO NOT PULL THEM UNLESS YOU WANT TO HELP WITH THE HISTORY
>> CONVERSION. Probably only the "restorical" branch won't change enough
>> to worry about from now, unless I get a significant new source of
>> revision information.
>>
>> See also
>> http://git.catalyst.net.nz/gitweb?p=perl-history-massage.git;a=blob;h=8f0af83c;hb=e1542030;f=README.txt
>>
>> I was meaning to get a bit further and announce it, but hidden in an
>> obscure branch of this flamewar will do for now ;)
>>
>> I've still got a bit of cleaning work to do, but I could really do with
>> perforce access, or preferably somebody with the appropriate knowledge
>> to extract all of the integrate / branch information from the repository
>> and give it to me in some easily mungable form. Actually the
>> information is mostly there in the commit messages, and it would
>> probably be good to go through the process of reverse engineering the
>> merge information from the commit log messages and comparing it to the
>> metadata - often the metadata is just as bad or worse than the manually
>> recorded information.
>>
>> Then there will just be the task of making sure that the maintenance
>> scripts work with the repository.
>>
>> And after that people can create their own little feature branches for
>> whatever new features they want and things won't suck. In fact moving
>> away from the outdated "blead/trunk/feature ghetto" development style
>> would probably be a good idea in general. Wikis suck even if they track
>> changes atomically over SSL WebDAV.
>>
>> Sam.
>