On Sat, Dec 6, 2008 at 7:15 AM, Grzegorz Kossakowski wrote:
>
> Some folks at Apache are experimenting with Git and we are currently seeking for the git-svn
> integration that fits our needs and infrastructure.
>
> After some evaluation we decided that our setup could be described using following points:
> a) our svn repository remains our main, official server where every committer is obligated to push
> their changes to at some time.
> b) we set up clone of svn repository using git-svn. One of our members, Jukka Zitting, maintains
> such a service here[1]. Such repositories should be usable both for our committers (that have rights
> to push to svn) and our contributors that want to contribute random patches
> c) we want carefully track who committed/contributed what
>
> Basically, a) implies b) and point b) looks little bit problematic right now.
> Jukka has set up his hosting using method described in his e-mail[2] which basically makes use of
> git svn. The major problem is that if one clones Jukka's repository then git svn information is not
> being cloned so committers have no means to push their changes to main, svn server.
Make sure you don't use the --no-metadata flag when setting up
git-svn. This will embed the metadata into commit messages, so git-svn
can rebuild it from scratch whenever it needs to. (You probably also
want git 1.6.1rc for incremental rebuild support). This also has the
advantage that you can see the svn revision number when looking at a
commit message.
> I've tried to play a little bit around with this issue and I tried to copy information from .git
> directory found on Jukka's server. This made me able to push my changes but git svn insisted on
> rebasing my repository using commits found in svn which is wrong. Basically we want such a setup
> that uses git repository (Jukka's clone) for pulling changes and local git svn for pushing changes.
> Git svn should never try to rebase local repository because this will lead to two different trees on
> two different machines so we won't be able to exchange and merge changesets.
svn doesn't really know what a merge is (not even 1.5). You MUST
rebase in order to commit to svn. This is a limitation of svn, not
git.
In terms of re-pulling from the git-svn mirror, git-svn will create
the same commits (with the same sha1s) from svn every time, so there
will be no conflicts there.
> Is it possible with Git right now?
Yes, but it might not be possible with svn, depending on which part of
the above "it" is.
> What if A was not fair and has rewritten a few commits coming from B so they contain malicious code?
> How we can detect something like that and how C be sure that what he merges is really work
> attributed by correct names?
If C doesn't trust A, C should not pull from A. C should pull only
from (trusted) B. Presumably B knows who (of A and B) did which work,
and B's repository can be trusted?
If neither of A or B can be trusted, then you have problems that a
computer cannot solve for you.
You could maybe use signed tags ("git help tag") - each contributor
could sign a certain tree state, and if you see commits attributed to
the other contributor after their last tag, you know something is
fishy. But that might be more effort than either you or your
contributors want to go through. And while it might help with
attribution problems, it still doesn't help with all the other
problems you might have with untrusted contributors.
Peter Harris
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
