Re: Git

Hello, Guy.  Do you have experience recovering a git clone from years  
of historical mistakes in other version control systems?  I could  
really use that right now.

Currently the big hurdle moving to git is repairing damage caused by  
years of newbie mistakes in RCS, CVS, and especially Subversion.   
While the current repository looks like a standard Subversion layout,  
it's not so historically.  git-svn clone does its best, but the  
results are a mess.

Specific problems:

git-svn clone puts all the release tags up through 1.003 on the master  
branch.  Release tags after 1.003 (through the present) are on a  
different branch.  I haven't learned why trunk (therefore Master)  
doesn't represent the most recent changes.

POE::Test::Loops and POE::Loop::{Event,Gtk,Tk} were created by moving  
files from trunk/poe to other directories in trunk.  This seems to  
have broken the files' revision chains.  I'd like to regain that old  
history.  I'm considering cloning the git repository up until the  
diversion point, rebasing a broken branch onto the clone, and then  
deleting all the files the project doesn't need.

Yuval Kogman's fine git-svn-abandon-fix-refs does wonders to recover  
branches and tags, but it relies on git-svn clone creating sane  
branches and remotes.

-- 
Rocco Caputo - [email protected]


On Oct 25, 2009, at 09:12, Guy Hulbert wrote:

> I discovered POE today due to a WNPP email to the debian-perl list.
>
> I'm very interest in it so I will be lurking here for now (mostly
> deleting everything that comes through after glancing at it).
>
> BUT.
>
> There was some stuff about Git in the "how to help" section.
>
> I have been using perl and git together for almost two years now.  I  
> am
> implementing a git-based web-site management scheme for a client.  We
> have tried svn and hg a bit as well but TortoiseGit suddenly reached a
> stage where using anything else seemed pointless.
>
> I can recommend git-hub highly (though I don't have much there).
>
> So if there's anything I can do (I've looked closely at and played  
> with
> git/hg and git/svn conversions) let me know.
>
> The main problem I have run into is that git (deliberately) has no
> locks.  So using a central repository is a cultural more than a
> technical problem and more of a problem in a business setting.
>
> -- 
> --gh
>
>