Junio C Hamano <gitster@xxxxxxxxx> wrote: > Eric Wong <normalperson@xxxxxxxx> writes: > > > 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? > > Actually I do. A major, if not primary, selling point of > git-svn has been that svn cannot do merges but if you import to > git you can, and I've had an impression that Sam's git-svn intro > alludes to this capability as well. Wow. My primary reasons for git-svn are completely different: speed and offline usability; and merging was not so much a concern for me. I've grown to prefer the patch + rebase model of keeping history linear in my work. This is different than from when I first picked up git: went overboard on merging just to see what kind of interesting graphs I could create in gitk :) So I didn't always prefer the recommended way git-svn works now. In the beginning there was the "git-svn commit" command, which has now been named "set-tree". I haven't used set-tree in ages, but I think it still supports preserving history of a git <-> git merging after commiting to SVN. The problem with set-tree was that it would either: a) make history ugly (with duplicate commits) for git users, as history never gets rewritten when using set-tree. or b) hide history from SVN users. > If I understand you correctly, your position is that the svn > side has the authoritative history when using git-svn, and we > should refuse to do anything on the git side that the resulting > history in svn cannot represent. I know and respect that you > have thought about the issues involved long enough before that > declaration of defeat, but at the same time, I would really hope > that we can come up with a workable compromise to allow merge > tracking on the git side. Yes. From what I gather, developers only use git-svn because they don't have enough swing within their group to replace SVN. I don't think encouraging git-svn users to isolate themselves with their own history and propagating less-useful history to the non-SVN users in a project is a good thing. > It probably does not even have to interoperate with people who > do their own merge tracking using svk. Perhaps something as > simple and ugly as recording the parent commit object names on > the git side as a trailer to the commit log message we push back > to svn would allow people who interact with the same svn > repository from their own git-svn managed git repository to > interoperate with each other? Of course, git-svn has gotten a lot more users than I expected it would, so maybe I'll implement it and see where it takes us. This could just be as simple as using the code for set-tree and instead using it to create revprops in SVN. I'd probably be inventing a fourth method of doing merge-tracking in SVN, though... -- 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
