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
Pod-Simple's history is complete.
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.
Re:Pushing tags
schwern on 2009-12-10T08:08:42
So why do people bitch about lightweight tags?
Re:Pushing tags
Aristotle on 2009-12-10T08:55:10
Beats me. I didn’t know they do. I’ve never used lightweight tags either, mind.
Re:Pushing tags
jhelwig on 2009-12-14T20:34:49
You can't GPG-sign a lightweight tag, so there's no concrete way to verify the tag as legitimate.
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
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 files.
another alternative is using interactive rebase to edit the gitpan imported commits that introduce the unwanted files (for instance for MANIFEST that would probably be the first one). git rm --cached MANIFEST && git commit --amend -C HEAD should do the trick. If there are any other versions of a file later in history that would result in an easy to resolve conflict.
Re:More complicated history
schwern on 2009-12-15T23:50:55
Global
.gitignore, AHHH!!! I totally forgot about that. I should have gitpan ignore the ignore file.
