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