Good morning, Dave. On Thu, Feb 24, 2011 at 4:17 AM, David A. Greene <greened at obbligato.org> wrote:> 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.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. ;) ...Takumi
NAKAMURA Takumi <geek4civic at 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 at 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 http://www-verimag.imag.fr/~moy/