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.

Reply via email to