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

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