On Sun, Dec 7, 2008 at 2:08 PM, Grzegorz Kossakowski wrote:
> 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?
Yes.
> 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.
To set up the remotes to mirror the remote svn-remotes, I do the clone manually:
git init
git remote add origin git://svn/mirror
git config --add remote.origin.fetch +refs/remotes/*:refs/remotes/*
git fetch
git reset --hard trunk
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.
This could all be in a common script you distribute to your users.
> 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.
"git help svn" mentions the rebuild only in passing. I'm not sure if
it is described in better detail elsewhere.
>> 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?
Yes[2].
>> 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.
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.
>> 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.
> 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.
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.
Peter Harris
[1] Not strictly true. git-svn does contact the svn server to see if
there are any revisions newer than the latest present in the git repo,
and will transfer those revisions (if any).
[2] Unless (a) someone edited the svn:log (or other) revprop in
between, or (b) you triggered the bug I saw reported (and fixed?) on
this list today. I've never personally triggered (b), but I have seen
(a).
--
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
