Hi Daniel, it makes sense, thanks a lot for your detailed answer. I guess this basically means that in most cases you cannot use git rebase if you're working with subversion repositories.
Simone On Wed, Oct 3, 2012 at 11:55 AM, Daniel P. Wright <d...@dpwright.com> wrote: > Simone (Oct03日（Wed）) >> > > Hello, I have a git local branch tracking a svn remote branch. I noticed > > that if I git rebase that branch onto another local branch (tracking a > > different svn remote branch) then the dcommit I do on the first goes to > the > > remote of the second. IOW > > > > branches: *feature1-local* tracks remote svn *feature1*, *master* tracks > > remote *trunk* > > > > git checkout feature1-local > > git rebase feature1-local master > > git svn dcommit <-- commits to *trunk* > > * > > * > > I would expect that dcommitting feature1-local would commit to feature1 > svn > > remote branch rather than the trunk. > > git-svn dcommits to the branch that the closest parent commit which has > been checked in is on[*]. You may have noticed that every commit which > has been "dcommit"ed has some "git-svn-id" metadata attached to the > commit message. git-svn steps back through the history until it finds a > commit containing this line, and then uses it to determine the branch it > belongs to. > > You can show which commit that is by executing the following: > > git show --first-parent HEAD --grep git-svn-id -1 > > If you have no commits in "feature1" (on svn), then your commits on > "feature1-local" (local commits, with no git-svn-id) will be reapplied > on top of the current "master", and tracing the commits back to the > first one with a git-svn-id will indeed give you one on the master > branch, pointing to "trunk". > > If you do have commits in "feature1", you have a rather bigger problem. > In SVN, the tree looks like this, say: > > --A--B--C--D--E--F <- trunk > \ > -G--H--I <- feature1 > > But in git, it looks like this: > > --A--B--C--D--E--F <- trunk > \ > -G--H--I <- feature1 > > That is to say, commits D, E, and F exist on feature1 in git, and are > BEFORE the feature commits G, H, and I. SVN has no way to rewrite > history like that, so when you try to "git svn dcommit" it.... I'm > actually not sure what it will do, but it won't be what you expect. > > I wrote on a similar subject on this list a week or so back -- I'm > afraid Google's web interface messes up the diagrams a bit, but you can > see the post here if you'd like: > > > https://groups.google.com/forum/?hl=ja&fromgroups=#!topic/git-users/8h1xHsTqShE > > The gist of it is, you need to be aware of which commits are local to > your git repository, and which have already been dcommitted to (or > pulled from) the subversion server. For the latter set, you have to be > careful about which git functionality you make use of, since subversion > doesn't support all of it. > > In the above case, I don't think there's any way around doing a > subversion-style merge from trunk to feature1 (you can do it in git, if > you like, by merging master into feature1-local with the --squash > option), and then again merging your changes from feature1 back into > master when you're finished. > > Hope that helps, > > -- Dani. > > [*] Most of the time. I found myself in the situation the other day > when it was *not* doing this, because I had done some weird > archaeology to my commit tree which resulted in the closest parent > commit's hash not matching what git-svn thought it should be. I had > to hack the /usr/share/perl5/vendor_perl/Git/SVN.pm file to skip the > hash check and perform the operation, after which it righted itself > and I could remove the hack. I still don't understand this > properly, but it shouldn't happen unless you're fiddling with > git-svn's internals anyway. > > > > > -- > > You received this message because you are subscribed to the Google > Groups "Git for human beings" group. > > To view this discussion on the web visit > https://groups.google.com/d/msg/git-users/-/0E8qpgzFE04J. > > To post to this group, send email to git-users@googlegroups.com. > > To unsubscribe from this group, send email to > git-users+unsubscr...@googlegroups.com. > > For more options, visit this group at > http://groups.google.com/group/git-users?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To post to this group, send email to git-users@googlegroups.com. > To unsubscribe from this group, send email to > git-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/git-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
