Authors CurseForge

I've spent the last few weeks researching the switch from SVN to Git (on Windows) and have found the most efficient method to be using Ruby with svn2git, as it seems to automate a lot of stuff I'd otherwise have to do manually (converting tags, etc). I'm using an alternative remote at the moment for the purpose of testing (so I don't screw something up), but had a few questions:

1. While svn2git does convert SVN tags to Git tags, it seems to leave the SVN tag commits intact, which in a graphical display makes it look like a bunch of short branches. The (WoWAce repo) guide recommends pruning empty commits (which makes sense) but doing so eliminates all of those SVN tag commits. It seems to me that this would be a good thing, as it cleans up the history but I'm not certain if it'll cause some sort of problem. Will it?

2. With all of the aforementioned tags converted to Git, will pushing them (--follow-tags, limiting to -as) force the packager to repackage all of them?

3. The above process leaves "remote (tracking?) branches" tied directly to the SVN repo plus some other SVN garbage. My plan was to push only the master (and tags) and then re-clone it so that my working copy was free of all of the SVN trash. Will that work or do I need to take some extra steps?

Thanks! :)

I read the comment about the tags issue, but I figured it would have been solved by now. It would seem logical to me to have the tags in place (and everything just how you want it) prior to the initial push. And I couldn't get the tag conversion script to actually do anything. Unless you're suggesting abandoning all irrelevant tags and just clean up the empty commits.

So what, just abandon all the old tags, clean up the empty commits and push it? Because I *can* do without the old tags, but I don't want any residual SVN "garbage" left over. The git-svn method creates more garbage than svn2git (or more aptly, svn2git does better at cleaning up after itself).

Well those repos show all of the original tags so clearly I'm missing something. I've ran the clone script (with the -s switch, since it's a standard lay out [ie, trunk, tags, branches]) but the tag conversion doesn't do anything. I think it has something to do with nesting and not providing a --prefix but I'm too tired to fool with it.

Edit: I was looking through the logs after using svn2git and it does exactly what the wiki guide suggests, including creating git-friendly tags and branches out of its svn counterparts. I'm going to see how it translates (after a bit of cleanup). I'll shoot it to an alternate and reclone it before pushing it here.

Thankfully this is a one-time (per add-on) deal. :p

Couple of things:

Phanx: In Git, tags are just pointers to a specific commit. Whereas in SVN, tags actually create their own commit. What I did was abandon the idea that I wanted to include all of the old tags since their only real purpose in Git is to trigger/mark a release. And I neither want, nor need those older "releases".

So there's basically two options:

1. Delete all the old tags and only use tags for current/future releases (what I'm doing).
2. Don't push tags along with your commit pushes. Instead, push only the tags you want packaged, separately. That way, you can keep your old tags locally, if only for the sake of history. You could also just leave them un-pushed until the new packager is brought online.

As far as the actual conversion process, I'm using Ruby and SVN2GIT. It makes it so much easier, as it clones the repo and converts the tags/branches to their git equivalents in one fell swoop. Then I just do some clean-up (included removing the old tags, as I've no use for them once I've logged them. But that's optional), push it to a staging repo on BitBucket, clone it back down so that the repo is clean of all the SVN stuff and then push it to WoWAce/GitHub.

Torhal: So with new packager, is it set up to only create packages if the current tag/commit is actually newer and is a higher "version"? Because rebasing dates is a pain in the ass. :P

Random blurb: Rebasing with SourceTree is SO much easier than using Bash if you need to fix typos, etc. Then you can follow it with a blanket rebase using the --committer-date-is-author-date flag for historical goodness. :)

Quote from Nevcairiel

Unfortunately, that still confused the old packager.
Once you turn packaging back on, it would get into its usual scheme of building broken old packages all the time.

Good thing it's got a long-overdue spanking coming. :p

Quote from Phanx

Right, but the instructions don't work as written, so there's simply no way to follow them exactly. I posted about this and your reply was "well, some other guy wrote that years ago, so who knows", so I did my best with the methods I could find that actually worked.

The cloning script works, but the branch/tag conversion script doesn't.

I think I used:

git for-each-ref --format="%(refname:short) %(objectname)" refs/remotes/tags \
| while read BRANCH REF
  do
        TAG_NAME=${BRANCH#*/}
        BODY="$(git log -1 --format=format:%B $REF)"

        echo "ref=$REF parent=$(git rev-parse $REF^) tagname=$TAG_NAME body=$BODY" >&2

        git tag -a -m "$BODY" $TAG_NAME $REF^  &&\
        git branch -r -d $BRANCH
done

Which preserves the original commit message, etc.

Quote from Phanx

This sounds miserable, as no GUI client for Git I've ever seen has this functionality -- they all just "push tags". If I wanted to type crap on the command line all the time, I'd use Linux. My first several computers ran DOS, and I don't see why anyone would voluntarily go back to that for basic everyday functionality. :p

SourceTree, from Atlassian (BitBucket.org guys), actually has an option to not push tags.



:)