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

Peter Harris pisze:

After the git clone, I do the following:
git svn init -s svn://repo/sitory
git svn rebase

No data is transferred[1], although 'git svn rebase' does spend a
minute or so reading the commit messages to rebuild its index.

I've tried this method with Cocoon repository
(http://jukka.zitting.name/git/?p=cocoon.git;a=summary) and got this error:

git clone git://jukka.zitting.name/cocoon.git
git svn init -s https://svn.eu.apache.org/repos/asf/cocoon/
git svn rebase
Unable to determine upstream SVN information from working tree history

git --version
git version 1.6.0.2

Any idea what's wrong here?

This could all be in a common script you distribute to your users.

Good suggestion.

"git help svn" mentions the rebuild only in passing. I'm not sure if
it is described in better detail elsewhere.

Ah, I didn't spot this earlier. Thanks.

If something is in A's tree, it is coming from A. Either A has
authority, or A has received authority from someone else, or A is
bringing the legal problem down on himself. When A says "Please Pull"
(or when A pushes) A is effectively saying "These changes are legally
mine to give you".

The Developer's Certificate of Origin 1.0 was designed to address this
issue; see also "Signed-off-by"

Of course, if it's a legal issue, make sure you consult your own lawyer.

I see. Thanks for insightful comments.

quoted

quoted

You could maybe use signed tags ("git help tag")...

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?

Typing in your GPG passphrase for every single little commit would be
even more tedious, IMHO.

Yep, that's true.

quoted

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?

That would be my policy. At the very least, I would have a human
review the tree before merging it.

Agreed.

Note that git was designed around a "git am" workflow, so it is very
efficient at dealing with large numbers of patches at a time.

Note also that you can do tree merging with an email-patch based
workflow, since git format-patch preserves parent information,
although it does take a little bit more work. See also: "git help am"
under --3way.

Thanks for all your valuable information. As soon as I resolve problem with git svn rebase I'll
start reading on how git am --3way works.

-- 
Best regards,
Grzegorz Kossakowski