Daniele Segato <daniele.bilug@xxxxxxxxx> wrote: > On Thu, Jun 10, 2010 at 9:04 PM, Eric Wong <normalperson@xxxxxxxx> 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.. Yes > 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? Yes, "git cat-file commit $commit" will show you the tree. > 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? Sort of, yes... Back in ancient times, there used to be a "git svn graft-branches" command which could automate what you're doing. It was removed in commit d05d72e07e49869fe988d4d99e6ac60711570db5 because it was largely unused. Perhaps you can resurrect it as a standalone command. I imagine it could be used for other import utilities, too. > >> 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? Err, actually, --svn-remote=main is probably preferred, these days. GIT_SVN_ID is --id=foo. Sorry for the confusion. > (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. I'll wait for others to answer that. I rarely encounter conflict-heavy merges, partly because my workflows are setup to avoid them. -- Eric Wong -- 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