Yes, that's quite true. It took me quite a while to figure that out when I first started using git-svn, and its non-sensicalness nearly put me off using git entirely. My workflow at this point is to use git-cherry-pick -e to pull in any changes from other branches, then delete the git-svn-id line. Essentially, merging using git-svn is almost entirely broken, since an inconsistent tool is worthless - you spend more time figuring out if it's going to break, and working around the breakage, than you save using it. Now, I'm not sure this is 100% the fault of git-svn. Perhaps keeping its metadata about which SVN branch it's connected to isn't the best thing, but git-merge is doing exactly what you ask for. Perhaps we need a merge command in git-svn that does the right thing? Although what that right thing would be, I'm not quite sure. Either way, there needs to be a BIG GIGANTIC WARNING in the git-svn manual that if you actually use git for what it claims to be great at (i.e., merging) you may be in for a world of pain, with your coworkers and boss coming at you with pitchforks and torches. Especially because there are so many git users who need to interoperate with SVN. On Tue, Aug 21, 2007 at 01:04:28PM +0200, David Kastrup wrote: > Benoit SIGOURE <tsuna@xxxxxxxxxxxxx> writes: > > > On Aug 15, 2007, at 12:17 PM, David Kastrup wrote: > > > >> > >> After having had several embarrassing occurences with git-svn dcommit, > >> I think it would not be amiss to mention in the docs just how git-svn > >> happens to figure out which Subversion remote it is associated with. > >> > >> One surprising relevation was that this association changed after a > >> git-rebase. > >> > >> It may be a general git thing, or it may be git-svn specific, but it > >> was not exactly what I expected. And the docs were not really that > >> helpful. > >> > >> In particular, man git-svn is completely silent about this. > > > > What I do usually is that I look in git log until I see a git-svn-id > > line: > > git-svn-id: https://svn.foo.com/svn/project/branches/bar@<rev-SVN> > > <Repository UUID> > > AFAIK git-svn dcommit will commit in the branch specified in the last > > git-svn-id. I also dcommitted in the wrong branch after a rebase > > because I imported commits from another branch and the topmost commit > > in git-log was "pointing to" a different branch. > > Sounds insane: apparently one result is that when you do a merge and > dcommit, the commit will go to the branch you merged. > > The whole point of merging is to stay on one's current branch. > > -- > David Kastrup > > - > 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 -- Dave Watson - 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
