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

On Sun, Dec 7, 2008 at 2:08 PM, Grzegorz Kossakowski wrote:

Peter Harris pisze:

quoted

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.

quoted

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

quoted

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.

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.

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