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

[Grzegorz Kossakowski <grek@tuffmail.com>]

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.

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

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