From: Daniele Segato <daniele.bilug@gmail.com>
Date: Fri, 11 Jun 2010 07:18:37 GMT
Subject: Re: Question about tracking multiple Subversion repository from the same git repository with git-svn
Message-ID: <AANLkTim_wx9lQ_IClmajo5etFKay0xPCTz1UrKilGWln@mail.gmail.com>
In-Reply-To: <20100610190417.GA15731@dcvr.yhbt.net>

On Thu, Jun 10, 2010 at 9:04 PM, Eric Wong <normalperson@yhbt.net> wrote:
>> 1. Is there a way to tell git that abc/trunk is a branch of svn/tags/1.2.3 ?
>
> You need to use grafts.

this one?
https://git.wiki.kernel.org/index.php/GraftPoint

seems what I need..

in this case, I had a question:

since if I use this feature my commit will have different SHA-1. I
used to write the commit SHA-1 in some of the svn tags. If I do this
they will no longer be valid.
I think with git SVN the "best" way to identify a commit is using the
"Tree" object SHA-1, it should be the same for every revision that
contains the same content...
so..
1b. Can I extract the tree sha-1 from a commit?
1c. Is there a way to get every commit pointing to to a tree?

Ideally I would do something like

git contain-tree <sha-1-of-the-tree>
[list of commit's here]

does this make any sense to you?

>> 2. can I rename svn-remote "svn" to something like "main" without side effect?
>
> You should be able to (and use GIT_SVN_ID=main in the env),
> though I haven't used these features in a while.

Renamed, thanks.
do you know if I can set a GIT_SVN_ID (default) per-repository instead
of using the environment
variable?
(since I use git-new-workdir it would be best if I can use a default
per workdir)

>> 3. after 2) can I also rename all the names of the remote branches to
>> main/* instead of svn/* ?
>
> It should be possible...  you need to edit $GIT_DIR/svn/.metadata, too.

thanks, did it.

>> 7. if the merge --squash cause a lot of conflicts is there a way to
>> split the conflict resolution across different persons?
>
> I'm not sure what you mean... multiple people working on the same
> working tree?  On a shared screen session?  I don't see why not.


no,
what I had in mind was a "migration team" to work on the migration of
the customization
to a product to the new version of the main product.

What I have in mind here is some kind of "selective merge".
For example...

I merge a group of commits, someone else, on another computer with
git-svn or subversion merge another part and so on..

like...

git merge --squash -- path/to/something
or something like

git merge --squash --interactive

this could give you a way to choose different paths you want to "merge".

I know this is not very like a merge but I hope I gave you the idea of
what I meant.

Regards,
Daniele Segato