{"thread":{"id":"20742","subject":"[git-svn] [FEATURE-REQ] track merges from git","startedAt":"2009-08-26T16:42:21Z","lastAt":"2009-09-06T22:15:51Z","messageCount":7,"participants":["Ximin Luo","Bryan Donlan","Eric Wong","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121812","messageId":"4A9565ED.4010608@cam.ac.uk","threadId":"20742","inReplyTo":null,"subject":"[git-svn] [FEATURE-REQ] track merges from git","fromName":"Ximin Luo","fromEmail":"xl269@cam.ac.uk","sentAt":"2009-08-26T16:42:21Z","receivedAt":"2009-08-26T16:42:21Z","isPatch":false,"sender":{"key":"xl269@cam.ac.uk","avatar":null},"body":"Hi,\n\nI'm have 2 separate svn projects from googlecode imported into a single git\nrepo. One is a semi-fork of the other, so I thought I'd be able to use git's\nmerge feature to repeatedly merge from the mother project (and possibly vice\nversa too).\n\nHowever, this doesn't happen. I \"git pull\" and this works fine, but when I \"git\nsvn dcommit\" back into svn, this rewrites my git history and it loses track of\nthe merge (and next time I try to pull, the same conflicts appear).\n\nFor now I just have a .git/info/grafts, but this doesn't get exported anywhere,\nso if other people \"git svn clone\" from svn, or \"git clone\" from my git repo,\nthey don't get the merge information.\n\nIt would be nice if git-svn saved the merge info somewhere instead of getting\nrid of it. #git tells me this is impossible at the moment, hence the mail.\nRelevant parts of the convo are pasted below.\n\nI understand if this is a low priority, but I don't think it would be a major\nPITA to implement (some suggestions are listed in the convo log). And it'd be\nuseful for people converting from svn to git.\n\nThanks for your time.\n\nX\n\nP.S. please don't troll me.\n\n(17:13:10) The topic for #git is: 1.6.4.1 | Homepage: http://git-scm.com |\nEveryone asleep or clueless? Try git@vger.kernel.org | Git User's Survey 2009!\nhttp://tinyurl.com/GitSurvey2009 | Channel log http://tinyurl.com/gitlog |\nMailing list archives: http://tinyurl.com/gitml | Gits on git:\nhttp://tinyurl.com/gittalks | Pastebin: http://gist.github.com/ | GSoC '09:\nhttp://socghop.appspot.com/org/home/google/gsoc2009/git\n(17:13:14) infinity0: hi\n(17:13:21) infinity0: i've used git-svn to import two svn repo\n(17:13:23) infinity0: repos*\n(17:13:28) infinity0: and used git to merge the two\n(17:13:45) infinity0: the problem is, when i git-svn dcommit back to svn,\ngit-svn rewrites my git history\n(17:13:50) infinity0: and loses the merge i just did\n(17:14:01) offby1: infinity0: of course\n(17:14:04) infinity0: how do i get it to retain knowledge of the merge?\n(17:14:11) offby1: infinity0: you don't.  Next questions.\n(17:14:16) infinity0: why not?\n(17:14:29) offby1: svn is incapable of storing a merge, at least in the sense\nthat we git people use the term \"merge\"\n(17:14:46) Grum: you should be able to store the result of a merge as a commit\n(17:14:51) offby1: sure\n(17:14:57) infinity0: sure, but why does git-svn have to rewrite my *git*\nhistory to remove knowledge of the merge?\n(17:15:02) offby1: but not as a \"merge commit\", whatever that might mean in svn\n(17:15:35) Grum: because it has to be representative of the svn repo after you\ndcommit there obviously\n(17:15:42) offby1: infinity0: it's trying to mirror the svn repository in your\ngit repository.  I assume the original, un-rewritten commits are still in your\ngit repository; they're just not pointed at by any branch.  Poke around in the\nreflog; I imagine you'll find 'em in there\n(17:16:09) infinity0: ok, but that's not useful if they're dangling\n(17:16:26) infinity0: it's trying to mirror the svn repo yes... but as you\nsaid, svn doesn't know about merges\n(17:16:26) ***offby1 idly wonders if it'd be possible for git svn to indeed\nstore merge commits, by applying the appropriate svn:mergeinfo properties\n(17:16:40) infinity0: i read a thread where it says those are different things\n(17:16:41) offby1: infinity0: I suspect you're using git svn for something for\nwhich it wasn't designed.\n(17:17:17) infinity0: would it be possible, in theory, to have git-svn store\nthe git merge information in eg. the same way it stores the git-svn tag in the\nsvn commit message\n(17:17:33) Grum: then just use svn?\n(17:17:37) Grum: and a postit?\n(17:18:01) infinity0: i'm trying to link two separate svn repos together via git\n(17:18:17) Grum: and that is just what offby1 said\n(17:18:30) infinity0: \"what\" is\n(17:18:40) Grum: I suspect you're using git svn for something for which it\nwasn't designed.\n(17:18:42) infinity0: as you all are saying, git merges and svn \"merges\" are\ndifferent things\n(17:18:58) infinity0: ok, but it would be possible to make git-svn have this\nfunctionality? or not\n(17:18:59) offby1: certainly\n(17:19:16) offby1: I fear not, since Eric Wong seems like a smart fella; if it\nwere doable, I suspect he'd have done it already.\n(17:19:21) offby1: But then ... who knows, maybe he's busy.\n(17:20:07) infinity0: well afaic it would just involve adding some extra\ngit-svn info to the svn commit messages, but meh\n(17:20:10) infinity0: i'll go file a bug\n(17:21:14) offby1: infinity0: if it were me, I'd shy away from cramming more\njunk into the svn commit messages; that strikes me as an unreliable storage medium\n(17:21:22) offby1: I'd use properties instead\n(17:21:24) Grum: ok lets do this properly\n(17:21:31) Grum: why do you want to 'merge' 2 svn 'repos' this way?\n(17:21:34) Grum: as you are not actually merging them\n(17:21:45) offby1: Grum: go, man, go!\n(17:21:58) infinity0: what do you mean \"not actually merging them\"\n(17:22:17) infinity0: they are \"actually merged\" in git\n(17:22:24) infinity0: then i git-svn dcommit and they become unmerged again\n(17:22:34) Grum: why do you want to merge them?\n(17:22:42) infinity0: so i can grab changes from one into the other\n(17:22:42) Grum: and what is your goal with dcommitting this?\n(17:22:57) infinity0: long story short, the two projects use svn on google code\n(17:23:06) infinity0: one is a semi-fork of the other\n(17:23:10) offby1: aaahhh\n(17:23:13) infinity0: i need to pull changes quite often\n(17:23:17) offby1: and you want to keep them in sync, kinda\n(17:23:19) infinity0: yeah\n(17:23:28) offby1: yeesh, dunno how I'd do that\n(17:24:09) infinity0: ok well i guess the only thing i can do atm is file a bug\nfor git-svn and tell people to manually add the .git/info/grafts\n(17:24:12) infinity0: but thanks for your info\n(17:27:24) infinity0: uh, where is the git bug tracker\n(17:27:40) Grum: its the mailinglist =)\n(17:27:41) sitaram: no bugs, so no tracker\n(17:27:44) sitaram: :\n(17:27:45) sitaram: :D\n(17:27:51) infinity0: lol\n(17:27:59) Grum: and erm you want a feature, its nt a bug you are reporting\n(17:27:59) Grum: s\n(17:28:00) infinity0: ok i'll post on the mailing list then.. *grumble*\n(17:28:08) infinity0: ok, *feature request :p\n(17:28:08) Grum: you are not using the tool for what it is meant to\n(17:28:13) Grum: and you can still do waht you want in either case\n(17:28:17) Grum: just not by merging\n(17:28:22) infinity0: well, how then?\n(17:29:48) infinity0: aww fuck 120 messages a day? oh come on... are\nnon-members allowed to post to it?\n(17:30:00) Grum: infinity0: just 120 yeah, and yeah they are\n(17:30:06) infinity0: ah ok\n"},{"id":"121819","messageId":"3e8340490908261206xc4156c4mb46e4c7de264df11@mail.gmail.com","threadId":"20742","inReplyTo":"4A9565ED.4010608@cam.ac.uk","subject":"Re: [git-svn] [FEATURE-REQ] track merges from git","fromName":"Bryan Donlan","fromEmail":"bdonlan@gmail.com","sentAt":"2009-08-26T19:06:14Z","receivedAt":"2009-08-26T19:06:14Z","isPatch":false,"sender":{"key":"bdonlan@gmail.com","avatar":null},"body":"On Wed, Aug 26, 2009 at 12:42 PM, Ximin Luo<xl269@cam.ac.uk> wrote:\n> Hi,\n>\n> I'm have 2 separate svn projects from googlecode imported into a single git\n> repo. One is a semi-fork of the other, so I thought I'd be able to use git's\n> merge feature to repeatedly merge from the mother project (and possibly vice\n> versa too).\n>\n> However, this doesn't happen. I \"git pull\" and this works fine, but when I \"git\n> svn dcommit\" back into svn, this rewrites my git history and it loses track of\n> the merge (and next time I try to pull, the same conflicts appear).\n>\n> For now I just have a .git/info/grafts, but this doesn't get exported anywhere,\n> so if other people \"git svn clone\" from svn, or \"git clone\" from my git repo,\n> they don't get the merge information.\n>\n> It would be nice if git-svn saved the merge info somewhere instead of getting\n> rid of it. #git tells me this is impossible at the moment, hence the mail.\n> Relevant parts of the convo are pasted below.\n>\n> I understand if this is a low priority, but I don't think it would be a major\n> PITA to implement (some suggestions are listed in the convo log). And it'd be\n> useful for people converting from svn to git.\n>\n> Thanks for your time.\n>\n> X\n>\n> P.S. please don't troll me.\n\nFor the particular use case you have, I suspect svk would be a better\ntool for merging between those two projects...\ngit-svn is rather specifically designed to only deal with a single\nupstream repository, you see, and it isn't very easy to change this to\naccept multiple repos.\n"},{"id":"121822","messageId":"4A95A12A.3060403@cam.ac.uk","threadId":"20742","inReplyTo":"4A95A032.3000801@cam.ac.uk","subject":"Re: [git-svn] [BUG] merge-tracking inconsistencies; Was: [FEATURE-REQ] track merges from git","fromName":"Ximin Luo","fromEmail":"xl269@cam.ac.uk","sentAt":"2009-08-26T20:55:06Z","receivedAt":"2009-08-26T20:55:06Z","isPatch":false,"sender":{"key":"xl269@cam.ac.uk","avatar":null},"body":"Ximin Luo wrote:\n> the tip of trunk is NOT a tip of test1\n\ner, that should read \"the tip of trunk is NOT a parent of the tip of test1\"\n\nX\n"},{"id":"121823","messageId":"4A95A593.4070002@cam.ac.uk","threadId":"20742","inReplyTo":"4A95A032.3000801@cam.ac.uk","subject":"Re: [git-svn] [BUG] merge-tracking inconsistencies; Was: [FEATURE-REQ] track merges from git","fromName":"Ximin Luo","fromEmail":"xl269@cam.ac.uk","sentAt":"2009-08-26T21:13:55Z","receivedAt":"2009-08-26T21:13:55Z","isPatch":false,"sender":{"key":"xl269@cam.ac.uk","avatar":null},"body":"Ximin Luo wrote:\n> The only difference between the two runs is that in the unfucked version, we\n> run \"git svn dcommit\" after every git commit.\n\nHmm, now that I think about it, the \"bug\" would be quite hard to \"fix\"...\n\nBasically, it happens if you try to dcommit a commit A which has two parents, B\nand X, where X is in a different branch, and hasn't already been dcommited. It\nwould seem that there isn't (in general) a way to detect whether X would become\n(ie. in the future) a dcommitted svn commit - and actually this might not even\nbe the case, if eg. someone \"svn commited\" before we could get that dcommit in.\n\nHowever about having git-svn outputting a warning when it detects merge\ncommits, one of whose parents is *not* a dcommitted commit, but does belongs to\na branch that is also being tracked by git-svn?\n\nSomething like \"Warning: commit aaaa has parent bbbb; however, parent bbbb has\nnot been dcommited to the remote svn yet. If you proceed with this dcommit, the\nmerge history will be lost; to preserve the history, dcommit the branch\ncontaining bbbb instead and then continue to dcommit this branch\"?\n\nX\n"},{"id":"122493","messageId":"20090905080337.GE22272@dcvr.yhbt.net","threadId":"20742","inReplyTo":"4A9565ED.4010608@cam.ac.uk","subject":"Re: [git-svn] [FEATURE-REQ] track merges from git","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-09-05T08:03:37Z","receivedAt":"2009-09-05T08:03:37Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Ximin Luo <xl269@cam.ac.uk> wrote:\n> Hi,\n\nHi, sorry for the late reply.\n\n> I'm have 2 separate svn projects from googlecode imported into a single git\n> repo. One is a semi-fork of the other, so I thought I'd be able to use git's\n> merge feature to repeatedly merge from the mother project (and possibly vice\n> versa too).\n> \n> However, this doesn't happen. I \"git pull\" and this works fine, but when I \"git\n> svn dcommit\" back into svn, this rewrites my git history and it loses track of\n> the merge (and next time I try to pull, the same conflicts appear).\n\nYou may want to try the \"set-tree\" function of git svn instead of\ndcommit, it was originally named \"commit\" back in the day  set-tree does\nnot rewrite any history.\n\nIt fell out of favor because you could end up with a lot of non-linear\nhistory making it difficult for sharing diffs with SVN-using cow-orkers.\n\nIt is useful if you don't want to share your individual changesets, but\npush your work upstream to the SVN repos as one big ugly change.\n\nBut if you want a staircase effect in gitk, set-tree can be used to make\nindividual commits where every change ends up as a merge (and you'll see\ntwo commits for every change you made)\n\n> For now I just have a .git/info/grafts, but this doesn't get exported anywhere,\n> so if other people \"git svn clone\" from svn, or \"git clone\" from my git repo,\n> they don't get the merge information.\n> \n> It would be nice if git-svn saved the merge info somewhere instead of getting\n> rid of it. #git tells me this is impossible at the moment, hence the mail.\n> Relevant parts of the convo are pasted below.\n\nIt should actually get logged to the unhandled.log file, but right\nnow I'm not aware of any tools that reads that file (which is designed\nto be machine parseable).\n\n> I understand if this is a low priority, but I don't think it would be a major\n> PITA to implement (some suggestions are listed in the convo log). And it'd be\n> useful for people converting from svn to git.\n\nI've considered stuffing git commit information in SVN properties,\nbut that information is likely to not even be useful to git users\nother than yourself\n\n> Thanks for your time.\n> \n> X\n> \n> P.S. please don't troll me.\n\nDon't worry, despite my domain name, it's been a long time since I've\ndone any real trolling :)\n\n> (17:13:14) infinity0: hi\n> (17:13:21) infinity0: i've used git-svn to import two svn repo\n> (17:13:23) infinity0: repos*\n> (17:13:28) infinity0: and used git to merge the two\n> (17:13:45) infinity0: the problem is, when i git-svn dcommit back to svn,\n> git-svn rewrites my git history\n> (17:13:50) infinity0: and loses the merge i just did\n> (17:14:01) offby1: infinity0: of course\n> (17:14:04) infinity0: how do i get it to retain knowledge of the merge?\n> (17:14:11) offby1: infinity0: you don't.  Next questions.\n> (17:14:16) infinity0: why not?\n> (17:14:29) offby1: svn is incapable of storing a merge, at least in the sense\n> that we git people use the term \"merge\"\n\nI'm not sure if that statement is still true with newer SVN versions;\nI still haven't had the time to look too hard at newer SVN features.\n\nOn the other hand, SVN could be storing \"merges\" that git simply can't\ntrack as merges; SVN branches and directories are interchangeable, so\nSVN could be merging from places that git isn't tracking at all or\nmerging individual files.\n\n> (17:14:46) Grum: you should be able to store the result of a merge as a commit\n> (17:14:51) offby1: sure\n> (17:14:57) infinity0: sure, but why does git-svn have to rewrite my *git*\n> history to remove knowledge of the merge?\n> (17:15:02) offby1: but not as a \"merge commit\", whatever that might mean in svn\n> (17:15:35) Grum: because it has to be representative of the svn repo after you\n> dcommit there obviously\n> (17:15:42) offby1: infinity0: it's trying to mirror the svn repository in your\n> git repository.  I assume the original, un-rewritten commits are still in your\n> git repository; they're just not pointed at by any branch.  Poke around in the\n> reflog; I imagine you'll find 'em in there\n> (17:16:09) infinity0: ok, but that's not useful if they're dangling\n> (17:16:26) infinity0: it's trying to mirror the svn repo yes... but as you\n> said, svn doesn't know about merges\n> (17:16:26) ***offby1 idly wonders if it'd be possible for git svn to indeed\n> store merge commits, by applying the appropriate svn:mergeinfo properties\n\nSome of should be mappable to git merges, it depends on the project and\nthe type of merge done.   As I said earlier, SVN could be merging\nfrom places git svn doesn't know about and can't track...  SVN can\nget extremely complicated :<\n\nI'm not sure how widely used that feature is used in the SVN world,\neither.\n\n> (17:16:40) infinity0: i read a thread where it says those are different things\n> (17:16:41) offby1: infinity0: I suspect you're using git svn for something for\n> which it wasn't designed.\n> (17:17:17) infinity0: would it be possible, in theory, to have git-svn store\n> the git merge information in eg. the same way it stores the git-svn tag in the\n> svn commit message\n> (17:17:33) Grum: then just use svn?\n> (17:17:37) Grum: and a postit?\n\nI don't agree with having git-specific metadata on the SVN side itself.\nOften times that git-specific metadata has SHA1s unique to the user that\ncommitted it, so it wouldn't be useful to anyone else unless users are\nmerging from each others git repos (which is not an easy/natural\nworkflow if SVN is the mainline).  Patch exchange is more\nreliable/easier...\n\nI've also worked in places where alternative tools are frowned upon, so\nsending git-specific metadata over to SVN should always be optional.\n\nThe majority of folks I've worked with on SVN-hosted projects have never\nknown about my git usage (that is changing as git popularity increases,\nhowever).\n\n> (17:18:01) infinity0: i'm trying to link two separate svn repos together via git\n> (17:18:17) Grum: and that is just what offby1 said\n> (17:18:30) infinity0: \"what\" is\n> (17:18:40) Grum: I suspect you're using git svn for something for which it\n> wasn't designed.\n> (17:18:42) infinity0: as you all are saying, git merges and svn \"merges\" are\n> different things\n> (17:18:58) infinity0: ok, but it would be possible to make git-svn have this\n> functionality? or not\n> (17:18:59) offby1: certainly\n> (17:19:16) offby1: I fear not, since Eric Wong seems like a smart fella; if it\n> were doable, I suspect he'd have done it already.\n> (17:19:21) offby1: But then ... who knows, maybe he's busy.\n\nI'm not smart but I am busy :)\n\nSummary of the git svn merge tracking situation:\n\nMapping git <-> git merges to SVN:\n\n  * already doable for the committing user with set-tree,\n    but makes history ugly for:\n\n    a) yourself (with every commit set-tree'd individually)\n    b) SVN users (single set-tree with the newest commit)\n    c) all of the above (varying granularity)\n\n  * Pushing git metadata to SVN will annoy SVN-only users\n\n  * Putting git metadata in SVN may not be useful since SHA1s\n    may be specific to the user that made that commit.\n\nMapping SVN <-> SVN merges to SVN via git svn:\n\n  * most likely to be doable, they'll become plain SVN <-> SVN merges,\n    see problems with getting SVN <-> SVN merges back to git, however...\n\nMapping SVN <-> SVN merges to git:\n\n  * SVN can represent merges that git can't, SVN can be/is extremely\n    complicated when it comes to merges.\n\n  * I don't see many projects (I care about) use SVN merge tracking,\n    which projects actually use it?  Maybe it's still too new and\n    distros/users are behind the upgrade curve...\n\nI've probably missed some, I've been dozing off while replying to\nemails...\n\n-- \nEric Wong\n"},{"id":"122510","messageId":"h7tana$j38$1@ger.gmane.org","threadId":"20742","inReplyTo":"4A9565ED.4010608@cam.ac.uk","subject":"Re: [git-svn] [FEATURE-REQ] track merges from git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-09-05T09:23:54Z","receivedAt":"2009-09-05T09:23:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Ximin Luo wrote:\n\n> For now I just have a .git/info/grafts, but this doesn't get exported anywhere,\n> so if other people \"git svn clone\" from svn, or \"git clone\" from my git repo,\n> they don't get the merge information.\n\nIn future version of git (I'm not sure if it is in master yet) there\nwould be refs/replace feature (grafts-like), which can be exported.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"122573","messageId":"4AA43497.8090101@cam.ac.uk","threadId":"20742","inReplyTo":"20090905080337.GE22272@dcvr.yhbt.net","subject":"Re: [git-svn] [FEATURE-REQ] track merges from git","fromName":"Ximin Luo","fromEmail":"xl269@cam.ac.uk","sentAt":"2009-09-06T22:15:51Z","receivedAt":"2009-09-06T22:15:51Z","isPatch":false,"sender":{"key":"xl269@cam.ac.uk","avatar":null},"body":"Eric Wong wrote:\n> You may want to try the \"set-tree\" function of git svn instead of\n> dcommit, it was originally named \"commit\" back in the day  set-tree does\n> not rewrite any history.\n> \n> It fell out of favor because you could end up with a lot of non-linear\n> history making it difficult for sharing diffs with SVN-using cow-orkers.\n> \n> It is useful if you don't want to share your individual changesets, but\n> push your work upstream to the SVN repos as one big ugly change.\n> \n> But if you want a staircase effect in gitk, set-tree can be used to make\n> individual commits where every change ends up as a merge (and you'll see\n> two commits for every change you made)\n\nMy problem no longer requires using set-tree (see below), but just to let you\nknow that when I try to set-tree, it gives:\n\n  $ git svn set-tree HEAD\n  config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned\nerror: 1\n\nIn my repo, \"remotes/git-svn\" doesn't exist; I have\n\n  $ git branch -a\n  * master\n    test1\n    remotes/test1\n    remotes/trunk\n\nbut the manual doesn't tell me how to select an svn-remote that's not \"git-svn\"..\n\n>> (17:16:40) infinity0: i read a thread where it says those are different things\n>> (17:16:41) offby1: infinity0: I suspect you're using git svn for something for\n>> which it wasn't designed.\n>> (17:17:17) infinity0: would it be possible, in theory, to have git-svn store\n>> the git merge information in eg. the same way it stores the git-svn tag in the\n>> svn commit message\n>> (17:17:33) Grum: then just use svn?\n>> (17:17:37) Grum: and a postit?\n> \n> I don't agree with having git-specific metadata on the SVN side itself.\n> Often times that git-specific metadata has SHA1s unique to the user that\n> committed it, so it wouldn't be useful to anyone else unless users are\n> merging from each others git repos (which is not an easy/natural\n> workflow if SVN is the mainline).  Patch exchange is more\n> reliable/easier...\n> \n> I've also worked in places where alternative tools are frowned upon, so\n> sending git-specific metadata over to SVN should always be optional.\n> \n> The majority of folks I've worked with on SVN-hosted projects have never\n> known about my git usage (that is changing as git popularity increases,\n> however).\n> \n>> (17:18:01) infinity0: i'm trying to link two separate svn repos together via git\n>> (17:18:17) Grum: and that is just what offby1 said\n>> (17:18:30) infinity0: \"what\" is\n>> (17:18:40) Grum: I suspect you're using git svn for something for which it\n>> wasn't designed.\n>> (17:18:42) infinity0: as you all are saying, git merges and svn \"merges\" are\n>> different things\n>> (17:18:58) infinity0: ok, but it would be possible to make git-svn have this\n>> functionality? or not\n>> (17:18:59) offby1: certainly\n>> (17:19:16) offby1: I fear not, since Eric Wong seems like a smart fella; if it\n>> were doable, I suspect he'd have done it already.\n>> (17:19:21) offby1: But then ... who knows, maybe he's busy.\n> \n> I'm not smart but I am busy :)\n> \n> Summary of the git svn merge tracking situation:\n> \n> Mapping git <-> git merges to SVN:\n> \n>   * already doable for the committing user with set-tree,\n>     but makes history ugly for:\n> \n>     a) yourself (with every commit set-tree'd individually)\n>     b) SVN users (single set-tree with the newest commit)\n>     c) all of the above (varying granularity)\n> \n>   * Pushing git metadata to SVN will annoy SVN-only users\n> \n>   * Putting git metadata in SVN may not be useful since SHA1s\n>     may be specific to the user that made that commit.\n> \n> Mapping SVN <-> SVN merges to SVN via git svn:\n> \n>   * most likely to be doable, they'll become plain SVN <-> SVN merges,\n>     see problems with getting SVN <-> SVN merges back to git, however...\n> \n> Mapping SVN <-> SVN merges to git:\n> \n>   * SVN can represent merges that git can't, SVN can be/is extremely\n>     complicated when it comes to merges.\n> \n>   * I don't see many projects (I care about) use SVN merge tracking,\n>     which projects actually use it?  Maybe it's still too new and\n>     distros/users are behind the upgrade curve...\n> \n> I've probably missed some, I've been dozing off while replying to\n> emails...\n> \n\nActually, it turns out that my original problem is simpler than any of these\nscenarios. What I was doing was git <-> git merges, where both of these git\nbranches were tracking *different* SVN branches (in my original case, from\ndifferent repos; in my simplified test case, from the same repo).\n\nConsider this scenario:\n\n----A0*-----A1---+\n     \\            \\\n      B0*----B1----B2\n\nbranchA: A1\nbranchB: B2\n\nWhere A0* and B0* have both been dcommited into their SVN branches, but A1, B1\nand B2 are present in the git repo only. A0* and B0* have the \"git-svn-id\" tag,\nand show my svn committer name; A1, B1 and B2 are still pure git commits, and\nshow my git commiter name.\n\nScenario 1:\n\nIf HEAD is at B2, and we try to \"git-svn dcommit\", then what happens currently\nis, git-svn will dcommit B1 then B2, re-writing them in the process (adding\ngit-svn-id and using the svn credentials instead of git credentials); however,\nit will *miss out* dcommitting A1. So we get this:\n\n----A0*-----A1----+\n     \\             \\\n      B0*----B1*----B2*\n\nbranchA: A1\nbranchB: B2*\n\nwhere B1* and B2* are the re-written versions of B1 and B2, with the added\ngit-svn-id and the svn committer name instead of the git committer name. There\nisn't a problem yet; but when we switch to branchA and dcommit, we get this:\n\n      +-----A1*\n     /\n----A0*-----A1----+\n     \\             \\\n      B0*----B1*----B2*\n\nbranchA: A1*\nbranchB: B2*\n\nWhere A1* is the re-written version of A1. But B2* still has A1 as a parent,\nand now we have an extra \"duplicate\" commit in our git repo. What's even worse\nis that A1* is **not a parent** of B2*, and so future merges on the branches\nwill potentially need to resolve conflicts that were resolved already when\nmerging (A1, B1) to B2.\n\nScenario 2:\n\nIf however, we dcommit A1, then B1, then B2, the commits will be re-written in\nsuch a way that the proper merge history is preserved, including the correct\nparents.\n\nIn one of the follow-up emails to my original posting, I supplied a test script\n(gitsvntest.sh) which demonstrates the 2 scenarios. You can use a GUI to review\nthe history graphs. I can re-send it if you can't find that email.\n\nI'm not sure how hard this is to fix; I guess it would involve making dcommit\ndetecting the case where a commit has more than 1 parent, and recursing down\nall the parents to see if they are tracking an svn branch.\n\nAt the very least, I think this situation can be detected and the user warned.\nIn switching from svn to git, git-svn was very helpful to me, but this\nbehaviour confused me completely - sometimes things worked fine, depending on\nthe order in which I dcommited stuff, so it was incredibly hard to figure out,\nespecially since at that time I had no understanding of the concept of object\ngraphs and rewriting commits and that sort of thing.\n\nX\n"}]}