Since I haven't heard a peep about it, I've gone ahead with the git migration.
The fedorahosted magic all points to git now.
r/o git URL
r/w git URL
The monotone access is still there until further notice, but let me know as
soon as you no longer care. The mtnelfutils group was renamed gitelfutils,
so everyone who had ssh-mtn access before has ssh-git access now (also).
Since there weren't any trunk commits since I did the test migration,
I just used that same git repo to start with. On top of that I've done one
git commit, adding a .gitignore file.
Please ACK that the git repo looks OK to you. If we need to rerun the
migration, we can still do it now. But soon we'll have fresh commits
waiting to come in and should be thoroughly done and fully committed to
using the new repo (no pun intended).
I just now noticed that tailor didn't migrate the named tags. But I
applied a little brute force and shell scripting, and made the right
correlations and pushed those tags. Note that migrated-from-mtn tags are
now "unsigned" tags, i.e. just refs/tags/* names for the revs. For future
release tags, we should use gpg-signed tags (git tag -s).
I also noticed that for branch mtn propagates that had to do merging, it
has produced a single git commit for the merge to trunk. For ones where it
just re-cert'd the rev, it seems to have the individual commit history.
So, for many of my .roland.pending merges the trunk hadn't changed and so
there is complete history. But for others, and for the .pmachata.threads
merges, there is just one trunk commit as if all the work merged from the
branch were applied as one big patch.
That all sucks a bit, but I have no interest in fighting more with tailor.
It's verified by the way I did my brute-force tag-migrating script that the
release tag revs had identical contents to their mtn tag counterparts. For
the detailed history in between, I trust tailor about as far as I can throw
a third of it and have the rest splatter around on the ground, or something.
But, feh. If you don't care real real hard, then I don't care at all.
The old mtn db's are always around somewhere. Let's get on with hacking
the code instead of hacking the repo setup.
If you have a venerable old checkout with miscellanea in it like I do,
then you can do:
git clone ssh://git.fedorahosted.org/git/elfutils.git
(cd eu-git; git reset --hard 12af5a28) # matches mtn rev 08bfa56b
mv _MTN _MTN~
mv eu-git/.git .
In my .git/config I have:
url = ssh://git.fedorahosted.org/git/elfutils.git
fetch = +refs/heads/*:refs/remotes/origin/*
push = +refs/heads/*:refs/heads/*
push = +refs/tags/*:refs/tags/*
The "push" lines make it push everything I define locally up
when I use "git push origin" (or plain "git push"). If you use
that, be sure not to litter your local repo with heads or tags
you didn't mean to publish.
I have migrated my two live branches using the mtn diff | git apply --index -p0
method. That is:
git checkout -b portable origin/master
mtn --db ~/.monotone/db/elfutils.mtn \
diff -r h:com.redhat.elfutils \
-r h:com.redhat.elfutils.roland.pending |
git apply --index -p0
That "checkout" line makes it so that on the branch just created, plain
"git pull" merges from origin/master after fetching it via ssh. All it
does is put some lines in .git/config, which you can just edit by hand
to set other branches to implicitly merge some branch.
The convention I've used is that my branches are roland/name (both on the
server and in my local git repo). I figure we should all use this
convention (fedora account name), and for any shared branch names outside
the username/ space we post here and get consensus on the use of the branch.
I don't really expect anyone else to touch the "portable" branch, but I
made it shared. It's what produces elfutils-portability.patch in the
Fedora rpms and is used to build on RHEL or similarly old systems.