GIT mirrors

Project Infrastructure LLVM Dev List Archives
1

Hello Everyone

I'm going to rebuild GIT mirrors to provide more consistent tags / branches.
Basically, the contents will be the same, but naming scheme will change.

So, trunk will go to svn/trunk, branches/* will got to svn/branches/*
and tags/* will go to svn/tags/*

This might break some scripts, etc. So, if anyone has some objections
wrt this - please let me know.

PS: First clang.git will be converted. In any case, the conversion
will be done offline and then the repos will be changed at once.

2

What does that mean for existing clones of the mirror?

Sebastian

3

Anton Korobeynikov <anton@korobeynikov.info> writes:

Hello Everyone

I'm going to rebuild GIT mirrors to provide more consistent tags / branches.
Basically, the contents will be the same, but naming scheme will change.

So, trunk will go to svn/trunk, branches/* will got to svn/branches/*
and tags/* will go to svn/tags/*

Thanks Anton! I'm glad you are willing to work this through as we all
learn how this stuff works. :slight_smile:

                            -Dave

4

Is this going to rewrite the entire history of everything on trunk? If I have a local git repo that has been pulling from the existing mirror, what will be the implications of your change?

5

Is this going to rewrite the entire history of everything on trunk? If I have a local git repo that has been pulling from the existing mirror, what will be the implications of your change?

The extra branches that Anton added to clang.git didn't rewrite anything.

Here's hoping it won't be necessary for llvm.git either.

/jakob

6

The extra branches that Anton added to clang.git didn't rewrite anything.
Here's hoping it won't be necessary for llvm.git either.

I was hoping that the rebuilt won't change the sha's and noone will
notice anything (well, except those who already branched out of
branches / tags).
But it seems that after rebuild stuff was changed (I really dunno,
why). So, we'll go other way.

In any case, it's unwise now to use published branches / tags :slight_smile:

7

The extra branches that Anton added to clang.git didn't rewrite anything.
Here's hoping it won't be necessary for llvm.git either.

I was hoping that the rebuilt won't change the sha's and noone will
notice anything (well, except those who already branched out of
branches / tags).
But it seems that after rebuild stuff was changed (I really dunno,
why). So, we'll go other way.

Just to be clear: we _really_ do not want all the sha's to change for trunk.

8

Just to be clear: we _really_ do not want all the sha's to change for trunk.

Yes. That's why I said there will be other way :slight_smile:

In any case - please try clang.git once again. It should contain new
branch/tag layout. If there will be some problems - let me know and
I'll revert to prev. repository.

9

Just to be clear: we really do not want all the sha’s to change for trunk.

Yes. That’s why I said there will be other way :slight_smile:

In any case - please try clang.git once again. It should contain new
branch/tag layout. If there will be some problems - let me know and
I’ll revert to prev. repository.

Perhaps my git-fu is just exceptionally weak, but I’m having difficulties figuring out how to use the new llvm.git repository.

This morning, I did a ‘git fetch’ and noticed it pulled new branches for the SVN releases and tags. So far so good. Then, I ran ‘git svn rebase -l’ but no commits were merged. Running a full ‘git svn rebase’ pulled several SVN revisions and appeared to commit them to my local repository, but username information appears to have been lost. Instead of the usual “Justin Holewinski <justin.holewinski@gmail.com>”, I see “jholewinski jholewinski@91177308-0d34-0410-b5e6-96231b3b80d8”.

Thinking the new repository layout is just not compatible with the old layout, I performed a fresh clone and did the usual:

$ git config --add remote.origin.fetch ‘+refs/remotes/git-svn:refs/remotes/git-svn’
$ git fetch
$ git svn init https://llvm.org/svn/llvm-project/llvm/trunk
$ git svn rebase -l

This seemed to work (luckily there were no upstream commits during this time), until I finished a commit and tried a ‘git svn dcommit’. It pushed my commit into the SVN repository, then proceeded to pull what seemed like 100+ different SVN revisions and merged them into my local tree. Running ‘git log’ after the commit showed my commit at the top, and then started with commits from 2001. I was concerned until I verified the problem was with my local repository and not with the upstream SVN repository!

It seems like with the current setup, I need to do a fresh git clone every time a new commit is made upstream. Otherwise, either ‘git fetch’ or ‘git svn rebase -l’ messes something up. Clearly I’m doing something wrong.

What am I missing here? Should the new layout affect the git workflow? Could you post a detailed overview of working with LLVM trunk through the git-svn bridge on llvm.org?

I thought maybe running from the svn/trunk branch would help, but that branch seems to contain history only up to 2001.

10

Hello Justin,

What am I missing here? Should the new layout affect the git workflow?

No. Stuff was just added. Trunk is still available as "master" as before.

11

Hello Justin,

What am I missing here? Should the new layout affect the git workflow?

No. Stuff was just added. Trunk is still available as “master” as before.

Alright, figured it out. Thanks to Tobias for the git insight!

The previous way I was using the git-svn bridge was to pull from refs/remotes/git-svn (learned from an older post on the list). However, git-svn does not appear to be a valid, up-to-date ref anymore. It only pulls history through March 10, which I assume is the around the time the layout change occurred. The fix is to have git-svn read from refs/remotes/origin/master instead of relying on refs/remotes/git-svn. Now it works great!

So, instead of:
git config --add remote.origin.fetch ‘+refs/remotes/git-svn:refs/remotes/git-svn’

I needed:
git config svn-remote.svn.fetch “:refs/remotes/origin/master”

Hopefully this will be helpful to others.

12

Maybe my git-fu isn't up to par... Ok, so I am trying this:

     git clone http://llvm.org/git/llvm.git
     cd llvm.git
     git config svn-remote.svn.fetch ":refs/remotes/origin/master"
     git fetch
     git svn init https://llvm.org/svn/llvm-project/llvm/trunk
     git svn rebase -l

The last command hangs for a long time, sucking up a lot of CPU cycles then spits out this message:

     Unable to determine upstream SVN information from working tree history

Anybody know what the problem is?

-Lenny

13

Do you really need to bother with git-svn when you have valid git mirror?

14

Oh, if it is a valid git mirror then I do not. A month or so ago, it did need that, but I guess since it has been changed over I don't anymore. Thanks for pointing out the obvious.

-Lenny