Re: How to clone git repository with git-svn meta-data included?

[Grzegorz Kossakowski <grek@tuffmail.com>]

Peter Harris pisze:
> 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.

Not sure what you exactly mean here. Do you mean that if metadata is included in commit messages
then there is an easy way to initialize git-svn after cloning the repo?

By easy I mean:
a) it does not require to much of interactive actions to be performed
b) it does not pull too much from svn server

Point b) is important because we usually have quite large repositories.

Also, could you point me to a place where this rebuild support is described? I would like to know
what our committer has to do after cloning from Jukka's server.

> 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.

Yep, I'm aware of the fact that history has to be flattened but I was more worried about the point
you address below.

> 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.

Just to make sure: so if one person pulls from git-svn mirror and another one pulls using git svn
rebase they result in the same tree right?

>> 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.

It referred mostly to cloning from git svn mirror and then being able to use git svn dcommit to push
changes back to svn. Since git svn data is not being cloned the question is how to recreate it.

>> 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.

Yep, I was having in mind the case when both A and B are untrusted. I don't want my computer to
check if something coming from A or B is safe or not I just want to know which bits are coming from
A and which from B.

This is really important for us because of legal reasons.

> 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.

The question is why Git doesn't sign all commits by default but only tags? Creating tags all the
time is rather tedious process and seems to have no sense, right?

Does it mean that with current Git design it's the best to not use advanced features of Git like
tree merging but simply go with posting e-mails with patches instead if contributors cannot be trusted?

Thanks for your reply.

-- 
Best regards,
Grzegorz Kossakowski