Re: Question about tracking multiple Subversion repository from the same git repository with git-svn

From: Daniele Segato <daniele.bilug@gmail.com>
Date: Jun 11, 2010, 07:18 UTC
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.

Show 5 quoted lines

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