Re: Git

Hi

Bit late, but this may be helpful if you want to run your own repo 
rather than using an outsourced site (github, etc)

http://github.com/sitaramc/gitolite

Then chuck up gitweb for the public web interface (or one of the many 
others)

> 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.

Fundamentally you have "git rebase -i" and gui tools equivalents

However, bear in mind that converting to git basically means just 
checking out each revision in your original vcs, then copying the state 
to the git repo and committing that change.  Any import script will just 
be a wrapper around that basic process and so you can write your own, do 
it manually, etc

> Currently the big hurdle moving to git is repairing damage caused by 
> years of newbie mistakes in RCS, CVS, and especially Subversion.  

Funny you say that - one of the things I like about git is that I find 
myself checking in 5 small changes with good comments versus 1 large 
commit with a poor comment when I used SVN.  I tended to use svn more 
like a kind of "snapshot" system and git I use more like a historical 
change record...

> 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.

My guess is that there was a fork here and you have one of more commits 
on the master branch which aren't in the 1.003 branch?

I would have thought running "git cherry" would show up differences and 
then switch to the master branch and do a git merge from the 1.003 
branch to fix it?  (Incidently, don't really alter the real branches, 
instead create a "wip" branch from master, then merge that with 1.003, 
if there are any problems you can blow it away.  Then when it's working 
simply rename master (or delete it) and rename your wip branch to master)

> 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.

This sounds sane - actually it should be much easier to do this than you 
think in git.  First import everything, then remember every commit can 
be used as a branch name, so just "git checkout a3354b1" and there you 
go - right back at that old commit.  Make it a proper named branch, 
mangle the repo to your hearts content and then merge in all the rest of 
the changes from the original branch.  If you want to tweak any commits 
then simply use "git rebase -i" and you can then juggle around the order 
of patches, split one patch to be many patches, merge patches to be a 
single change, etc. Always do all your work in a separate branch so that 
you can blow it away if you don't like it

Also remember that git cherry is incredibly powerful for finding 
unmerged changes.  It will often even work through file renames and 
large cut'n'paste changes (cool!)

I didn't read the original thread, so no idea if this is actually 
helpful... Sorry

Good luck

Ed W