Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

schwern (1528)

  (email not shown publicly)
AOL IM: MichaelSchwern (Add Buddy, Send Message)

Schwern can destroy CPAN at his whim.

Journal of schwern (1528)

Friday December 04, 2009
02:33 AM

gitPAN's first success story

[ #39974 ]

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://
        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

Pod-Simple's history is complete.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • gitPAN is currently using lightweight tags, so they have to be pushed too.

    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.

  • 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

    • Global .gitignore, AHHH!!! I totally forgot about that. I should have gitpan ignore the ignore file.