Git repo ready!

[John Ralls]

On Mar 12, 2011, at 10:11 AM, John Ralls wrote:

> 
> On Mar 12, 2011, at 8:01 AM, Christian Stimming wrote:
> 
>> Am Samstag, 12. März 2011 schrieb John Ralls:
>>>>>>>>>> However, I think the git repo is missing many of the recent tags,
>>>>>>>>>> e.g. the 2.4.3 tag.
>>>> 
>>>> Sorry to bug you again, but the tags (e.g. 2.4.3) seem to belong to a
>>>> different branch than origin/master. Do I see the same repo as you do? On
>>>> my local repo, origin/master is 4d1754d2492c8b3118418b0c378feda5e71053aa
>>>> "Updated Dutch translation ..."
>>>> but the tag 2.4.3 is
>>>> e2d71eb340534907c0b2e69e3f4acf2490beb09f where instead it should be
>>>> something right next to c6314a4aa5c6923bbf7c54247c52950a4987758f "Only
>>>> show the Save As dialog..."
>>> 
>>> There is no master unless you create it (I recommend in the wiki article
>>> that you create it as a tracking branch on trunk). The main branch is
>>> "trunk", and that's the branch you should have checked out when you commit
>>> back to subversion (until we set up the 2.4 branch, at which point you'll
>>> be able to commit back to that branch as well).
>> 
>> Well. I've just created a newly cloned local repo, exactly following your 
>> instructions from the wiki page. I was wrong when talking about 
>> "origin/master"; instead, I meant "origin/trunk". Yes, that *is* the branch I 
>> have checked out.
>> 
>>> I don't know what repo you're looking at; let's look at what's on Github.
>>> Select 2.4.3 from the "switch tags" dropdown, then switch to the "commits"
>>> view.
>> 
>> I've been looking at my local clone of the github repo. Your explanation of 
>> the 2.4.3 tag is identical to what I see with gitk in my local repo, where the 
>> 2.4.3 tag is e2d71eb340534907c0b2e69e3f4acf2490beb09f which you've just 
>> confirmed. The problem is somewhere else:
>> 
>> My point is that this tag isn't created on the correct trunk branch. Its one 
>> parent currently is 88c6a5be95 (SVN r20344) whereas instead its parent should 
>> have been c6314a4aa (also SVN r20344). The former isn't a parent of github's 
>> "trunk" whereas the latter is, so the latter is where the tag should be.
> 
> Ah, I see. It appears that git-filter created a separate chain of commits when I rebuilt the tags. I'll have to figure out how to rebase it back to a single chain. I may not get to that until tomorrow.

I fixed it, but in order to do so I had to get rid of the extra merges of old subversion topic branches to show a nice git-history. (Basically I had to discard the references from the filter-branch that incorporated them. If anyone wants the grafts file I can put it somewhere, maybe git-helper-scripts.) That of course changed all of the SHA1s, so I had to delete and reload the Github repository.

If you've done work in your clone of the older repository which you haven't yet committed to subversion, you can do one of the following:

Get it finished up and commit it to subversion. This is the easiest, because the mirroring program will retrieve it from subversion and add it to the new repository. You can delete the old repo and clone afresh and you're ready to go.

If that's not practical (perhaps you don't want it to go to subversion, or there's a new revision in subversion that will conflict with it and you need to merge from the repo before you can commit):

Move the existing repository aside and clone afresh. Go to the saved repository. Commit any uncommitted work. (If it's not really ready for a commit, no matter. You can `git reset --soft HEAD^` to undo that last commit after you've gotten everything moved) and run `git format-patch`. If you were working on a feature branch, pass the trunk commit that is the root of your branch as the "since" argument, otherwise pass the last trunk commit with a subversion revision number in the comments. 

Now switch to the new repo and find the SHA1 for the same revision that you used for the root of your patches. The SHA1 will be different from the one in the old repo; that's why you have to do this with patches. If it happens to be the current HEAD, you don't need to make a branch to receive your patches. (You can, of course, but you don't have to.) Otherwise make a branch with `git checkout -b branchname SHA1` and replay your patches with `git am path/to/old/repo/*.patch`. If you were working in a feature branch, you've got your new feature branch and you're ready to go. If you were working on trunk, rebase the branch onto trunk and delete it. Copy over any not-version-controlled files from the old repo and delete it.

Regards,
John Ralls