threads / discuss / 12853

Hand-rolling migration to Git

Subject: Hand-rolling migration to Git

## tl;dr

4 messages between Mar 25, 2008 and Mar 31, 2008.

replies: 3people: 3as markdown or json

Peter Karlsson· Mar 25, 2008, 10:03 UTC · lore
Hi!

I am looking for documentation on how to hand-roll a conversion to Git, but I keep getting lost in the maze of similar-looking man pages. Is there a tutorial, howto, or perhaps even just a list of recommended man pages to read on importing project changes to Git?

I have projects of two different kinds that I need to import:
1. The "make a copy of the source code directory and edit the new copy"
source management system. I need to be able to import one directory at
a time, each describing a version controlled state. The date stamp on
the commits should probably be the most recent file in each directory.
2. A piece of software using PVCS (a RCS-like version control system
with added support for parallel development (using a locking model)). I
have a complete "trail file" which lists all commits done to the
repository in chronological order since the repository was created, and
can use that as a base. Since it has no concept of an atomic commit, I
need to semi-manually join commits by walking the trail file and
comparing lock sets, time stamps, commit messages and authors.

I can probably make the output from (2) look like from (1), so I basically just need to find a pointer to information on how to (re-)create the history with Git.

-- 
\\// Peter - http://www.softwolves.pp.se/
Johan Herland· Mar 25, 2008, 10:14 UTC · re: Peter Karlsson · lore

Re: Hand-rolling migration to Git

On Tuesday 25 March 2008, Peter Karlsson wrote:
Show 25 quoted lines
> Hi!
> 
> I am looking for documentation on how to hand-roll a conversion to Git,
> but I keep getting lost in the maze of similar-looking man pages. Is
> there a tutorial, howto, or perhaps even just a list of recommended man
> pages to read on importing project changes to Git?
> 
> I have projects of two different kinds that I need to import:
> 
> 1. The "make a copy of the source code directory and edit the new copy"
> source management system. I need to be able to import one directory at
> a time, each describing a version controlled state. The date stamp on
> the commits should probably be the most recent file in each directory.
> 
> 2. A piece of software using PVCS (a RCS-like version control system
> with added support for parallel development (using a locking model)). I
> have a complete "trail file" which lists all commits done to the
> repository in chronological order since the repository was created, and
> can use that as a base. Since it has no concept of an atomic commit, I
> need to semi-manually join commits by walking the trail file and
> comparing lock sets, time stamps, commit messages and authors.
> 
> I can probably make the output from (2) look like from (1), so I
> basically just need to find a pointer to information on how to
> (re-)create the history with Git.
Take a look at git-fast-import. It should be relatively easy to write a small script that converts from either (1) or (2) to a stream of git-fast-import commands.
Have fun! :)
...Johan
-- 
Johan Herland, <johan@herland.net>
www.herland.net
Johannes Schindelin· Mar 25, 2008, 10:39 UTC · re: Johan Herland · lore

Re: Hand-rolling migration to Git

Hi,
On Tue, 25 Mar 2008, Johan Herland wrote:
Show 31 quoted lines
> On Tuesday 25 March 2008, Peter Karlsson wrote:
> 
> > I am looking for documentation on how to hand-roll a conversion to 
> > Git, but I keep getting lost in the maze of similar-looking man pages. 
> > Is there a tutorial, howto, or perhaps even just a list of recommended 
> > man pages to read on importing project changes to Git?
> > 
> > I have projects of two different kinds that I need to import:
> > 
> > 1. The "make a copy of the source code directory and edit the new 
> >    copy"  source management system. I need to be able to import one 
> >    directory at a time, each describing a version controlled state. 
> >    The date stamp on the commits should probably be the most recent 
> >    file in each directory.
> > 
> > 2. A piece of software using PVCS (a RCS-like version control system 
> >    with added support for parallel development (using a locking 
> >    model)). I have a complete "trail file" which lists all commits 
> >    done to the repository in chronological order since the repository 
> >    was created, and can use that as a base. Since it has no concept of 
> >    an atomic commit, I need to semi-manually join commits by walking 
> >    the trail file and comparing lock sets, time stamps, commit 
> >    messages and authors.
> > 
> > I can probably make the output from (2) look like from (1), so I 
> > basically just need to find a pointer to information on how to 
> > (re-)create the history with Git.
> 
> Take a look at git-fast-import. It should be relatively easy to write a 
> small script that converts from either (1) or (2) to a stream of 
> git-fast-import commands.

Yeah. To get inspiration how the scripts should look like, read contrib/fast-import/import-tars.perl, or look at http://repo.or.cz/w/fast-export.git

Hth, Dscho

Peter Karlsson· Mar 31, 2008, 06:23 UTC · re: Johannes Schindelin · lore

Re: Hand-rolling migration to Git

Johannes Schindelin:
>> Take a look at git-fast-import. It should be relatively easy to write a 
>> small script that converts from either (1) or (2) to a stream of 
>> git-fast-import commands.
> Yeah.  To get inspiration how the scripts should look like, read 
> contrib/fast-import/import-tars.perl, or look at 
> http://repo.or.cz/w/fast-export.git

I've played a bit with git-fast-import, but I sort of failed to get something working for PVCS export (see other thread).

The import-tars.perl script, however, was a very good idea. The simplest solutions for the multiple-directories source I had was just to tar it up and feed through import-tars.perl. After importing it into Git and repacking it with a suitably large --window argument, I had a Git repository of 64 megabytes, down from the four or so gigabytes of uncompressed directories. That did include removing some object files, though (but keeping some .exe's).

-- 
\\// Peter - http://www.softwolves.pp.se/

← back to recent threads