repo.or.cz GIT mirrors

Hello Everyone

As you might already know, git mirrors of llvm repository started from
repo.or.cz mirrors, where stuff was pushed almost by hands out of
git-svn local copy. Right now we have official and automatically
updated GIT mirrors on llvm.org and thus repo.or.cz mirrors look a bit
redundant. However, they might still be useful, but definitely not
within the current "push mode". It is possible to convert them to
plain GIT mirrors of llvm.org GIT mirrors with automatic pulling, but
this, in fact, will require us to delete repo.or.cz repos and recreate
them from scratch.

I hope this would affect only forks, from which only 1-2 seem to be
active (and hopefully they can be just recreated on top of new
projects).

Any objections for such procedure? Maybe someone will have better idea?

Anton Korobeynikov <anton@korobeynikov.info> writes:

Hello Everyone

As you might already know, git mirrors of llvm repository started from
repo.or.cz mirrors, where stuff was pushed almost by hands out of
git-svn local copy. Right now we have official and automatically
updated GIT mirrors on llvm.org and thus repo.or.cz mirrors look a bit
redundant. However, they might still be useful, but definitely not
within the current "push mode". It is possible to convert them to
plain GIT mirrors of llvm.org GIT mirrors with automatic pulling, but
this, in fact, will require us to delete repo.or.cz repos and recreate
them from scratch.

Do git repositories cloned from git-svn mirrors work properly? For
example:

                         svn
                          ^
                          >
                          >
                          V
                       git-svn
                       / \
                      / \
                git clone A git clone B

I don't think one can share commits from clone A to/from clone B without
going through the parent git-svn repository. Is that right? I recall
having read something about that somewhere.

If this is a problem, it might be counterproductive to provide a
repo.or.cz mirror at all, because people will think it's a "proper" git
repository when it really isn't.

BTW, the llvm.org git-svn mirror is for trunk only, right? How
difficult would it be to include the latest release tag in the git-svn
mirror (RELEASE_28 right now)? This would greatly help people that work
with the latest release of llvm rather than trunk.

                            -Dave

Good morning, Dave.

Do git repositories cloned from git-svn mirrors work properly? For
example:

                    svn
                     ^
                     &gt;
                     &gt;
                     V
                  git\-svn
                  /     \\
                 /       \\
           git clone A  git clone B

I don't think one can share commits from clone A to/from clone B without
going through the parent git-svn repository. Is that right? I recall
having read something about that somewhere.

Maybe sure on git-svn's branch (eg. master).
"master" should never be pushed to "git-svn", but "git pull --rebase"
should be done.

Each clonee should do "git-svn dcommit" individually.
(and it would be happier if you did "git pull --rebase llvm.org)

Of course, other branches may be push/pull-ed among repos. It is git!

If this is a problem, it might be counterproductive to provide a
repo.or.cz mirror at all, because people will think it's a "proper" git
repository when it really isn't.

Which do you mention to, "Anton's repo" or "(coming) cloned repo from llvm.org"?
With latter, I don't think there might be any matters.
(as far as a person would never do "git push -f repo.or.cz master")

BTW, the llvm.org git-svn mirror is for trunk only, right? How
difficult would it be to include the latest release tag in the git-svn
mirror (RELEASE_28 right now)? This would greatly help people that work
with the latest release of llvm rather than trunk.

+1. Anton, please provide *official* release branches. :wink:

...Takumi

NAKAMURA Takumi <geek4civic@gmail.com> writes:

I don't think one can share commits from clone A to/from clone B without
going through the parent git-svn repository. Is that right? I recall
having read something about that somewhere.

Maybe sure on git-svn's branch (eg. master).
"master" should never be pushed to "git-svn", but "git pull --rebase"
should be done.

Right.

Each clonee should do "git-svn dcommit" individually.
(and it would be happier if you did "git pull --rebase llvm.org)

Yep.

Of course, other branches may be push/pull-ed among repos. It is git!

Does this mean that clone B can pull from clone A and vice-versa? What
happens when someone does a pull from A to B and then commits to master
(after rebase) from B? What if someone then commits from A to master
(after rebase)?

                           -Dave

greened@obbligato.org (David A. Greene) writes:

Each clonee should do "git-svn dcommit" individually.
(and it would be happier if you did "git pull --rebase llvm.org)

Yep.

Of course, other branches may be push/pull-ed among repos. It is git!

Does this mean that clone B can pull from clone A and vice-versa?

The problem is the "rebase" step. Rebase is great to keep your history
clean, but rewrites history. If you had local commits C1 and C2,
"git pull --rebase" will replay C1 and C2 on top of the new HEAD,
creating new commits C1' and C2' that look like C1 and C2 without being
the same. As opposed to that, "git pull" (without rebase) creates a
merge commit on top of C2 and the new HEAD.

This means that if someone pulled your C1 and C2, you rebased, and
the other clone pulls again, it won't notice that C1/C2 and C1'/C2' are
meant to be the same, and do awkward things instead of a clean merge.

So, you may pull from a clone to another, but you cannot alternatively
pull from a clone to another and rebase on upstream without getting into
trouble.

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

So, you may pull from a clone to another, but you cannot alternatively
pull from a clone to another and rebase on upstream without getting into
trouble.

Ah yes, that makes sense. Hrm...

                           -Dave