Peter Baumann <waste.manager@xxxxxx> wrote: > On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote: > > Hi there, > > > > when running "git-svn dcommit" git-svn tries to find the svn-URL of the > > current branch int git by looking for the most recent git log-entry > > corresponding to a commit in svn (see working_head_info in git-svn). In > > case a merge just happended this might be the URL of another branch. Would > > using "log --first-parent" instead of a plain "log" take care of this > > problem or would it have other undesirable consequences? > > > > I had this situation, too. > > > a = svn branch 'a' > m b = svn branch 'b' (in my case, it was trunk) > / \ m = a merge of branch 'a' and 'b', not yet commited to svn > a b > > So trying to dcommit m, git svn can't figure out on which branch, as 'a' > and 'b' are both reachable. I had to use a graft file to lose one of the > parents, which let git-svn commit to SVN. > > So for a short fix to get the work done, you could create a graft file > where you fake m to only have one parent. Ok. I'm regretting making 733a65aa5d33196fac708ebd12a98a1060cbf3c2 now. It doesn't introduce the problem, but it does encourage it. I still happen to believe allowing git-merges in repositories that try to interoperate with SVN is just giving rope for users to hang themselves with. Junio: Would you object to having git-merge spew a big fat warning and/or outright refuse to let git-merge run on git-svn repositories? 13c823fb520eaf1cded520213cf0ae4c3268208d was introduced to allow using git-format-patch + git-am to apply patches from other branches in SVN, which is the recommended way to do "merging" with git-svn. > On the longer run, I would make sense to have an option to explicitly > specify on which SVN branch 'git-svn dcommit' should operate. Patches welcome :) -- 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
