On Wed, Apr 04, 2012 at 10:19:33AM -0500, Jonathan Nieder wrote: > tags 667488 + upstream wontfix > forwarded 667488 http://thread.gmane.org/gmane.comp.version-control.git/194689 > quit > > Hi Christian, > > Christian Engwer wrote: > > > A branch should either be a local copy of an svn branch, or a remote > > tracking branch. After a "git svn dcommit" a remote tracking branch > > could not be synced with the git remote due to the rebase that occured > > during the dcommit. > > Could you say a little more about what problem you are trying to fix, > for example with some sample commands, what the user expects to happen, > and what happens instead? > > If I understand correctly you are saying that "git svn dcommit" should > change its behavior based on where the current branch is set to pull > from, which sounds like a very bad idea. So I'm marking the bug as > wontfix for now but am still listening.
Consider the following: You have an svn repository as "main upstream" (trunk). To develop a new feature, you setup a git repository (on the server) available as (remote/newfeature). It is basically a branch from (trunk). On your machine you want to use both remote repositories, as you sometimes just want to use the trunk and sometimes work on the new feature. You setup master to follow trunk. Then you create a branch newfeature as a remote-tracking branch of remote/newfeature. I'd consider the "-t" option when creating the newfeature branch as an explicit statement to follow the git-repository and not the svn-repository. In theory it might be nice to follow both, but an "svn dcommit" will implicitly do a rebase which in turn might lead to problems with the git upstream repository, at least if fast-forward is required, which is the default. The different concepts of history in svn and git make it (nearly) impossible to follow a git and an svn remote. I have been discussing with colleagues and we didn't come up with a use-case, where you would like to follow a git repository and upload to svn, but we experienced problems as described before. Perhaps you can convince me, that the current behavior is in deed useful :-) Cheers Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
