All the Perl that's Practical to Extract and Report
use Perl Log In
schwern (1528)
(email not shown publicly)
http://schwern.net/
AOL IM: MichaelSchwern (Add Buddy, Send Message)
Jabber: schwern@gmail.com
Schwern can destroy CPAN at his whim.
gitPAN's first success story
Sitting next to David Wheeler at a bar, he co-maintains Pod::Simple. The repo is on github. Previously it was in SVN. Before that, Sean Burke's hard drive. The SVN repo was imported into git, but as Sean had no repo they're left with a history gap. He wants that history back.
I imported Pod-Simple into gitPAN for him, then went about pasting his repository on top of gitPAN's. This means a rebase. First, we fetched the gitpan repo into his repository.
git remote add gitpan git://github.com/gitpan/Pod-Simple.git
git fetch gitpan
Then we find the first commit to David's repo and note the date: Nov 18th, 2005. We find the commit just before that in gitpan/master, 3.02, and its tagged 3.02. Then rebase all of David's repo on top of that tag.
git rebase --onto 3.02 --root master
That replays all of master on top of the tag 3.02 from gitpan. Ta da! Done. You can remove the gitpan remote.
git remote rm gitpan
As a final bit of cleanup, we made sure all the release tags after 3.02 are pointing to David's commits and not gitPAN's. I'll leave retagging as an exercise for the reader.
Push that (has to be forced, since its not a fast-forward) and it done.
git push origin master -f
gitPAN is currently using lightweight tags, so they have to be pushed too.
git push --tags
help them think they understand.
--Larry Wall
Pushing tags (Score:1)
It doesn’t matter whether they’re lightweight or annotated. You always have to push tags in git explicitly. This is a conscious design choice.
Re: (Score:2)
So why do people bitch about lightweight tags?
Re: (Score:1)
Beats me. I didn’t know they do. I’ve never used lightweight tags either, mind.
Re: (Score:1)
More complicated history (Score:1)
More complex history (with multiple holes), can be reconstructed with the grafts file and git filter branch.
Secondly, note that I still haven't figured out a sane default for the tree importing WRT .gitignore. If there's a global gitignore in ~/.gitconfig then that gets applied (perhaps wrongly).
Many times people ship files they don't want in VCS and vice versa. Obviously for unshipped files there's nothing gitpan could do but in the other direction git filter branch would be useful for pruning out unwanted
Re: (Score:2)
Global .gitignore, AHHH!!! I totally forgot about that. I should have gitpan ignore the ignore file.