{"thread":{"id":"1588","subject":"[RFC] Importing from a patch-oriented SCM","startedAt":"2005-08-19T07:04:24Z","lastAt":"2005-08-19T16:22:29Z","messageCount":5,"participants":["Martin Langhoff","Junio C Hamano","Johannes Schindelin","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7548","messageId":"46a038f9050819000417ed436e@mail.gmail.com","threadId":"1588","inReplyTo":null,"subject":"[RFC] Importing from a patch-oriented SCM","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-19T07:04:24Z","receivedAt":"2005-08-19T07:04:24Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"I am drafting an import script to turn a GNU Arch into a GIT archive.\nImporting the branches and commits increamentally is reasonably\nstraightforward -- or so it seems so far. Note: the repository\nmanipulation is based on cvsimport -- so my knowledge of the git repo\ninternals is still pertty close to zero.\n\nEach patchset has a unique identifier, and can carry metadata with the\nidentifiers of the patches it \"includes\". If you are using gnu arch,\nwhen you merge across branches, it'll know to skip a particular\npatchset if it has been applied already. AFAICT there is no such\nconcept in GIT, and I wonder what to do with all this metadata about\nmerges.\n\nMy proto-plan is to keep track of merged stuff (in a cache file\nsomewhere), and if a particular merge means that the branches are\nfully merged up to the last patch of the series (if no commits from\nthe source branch have been skipped) mark it as a merge in GIT.\n\nIf the merges have been done out-of-order, that may show up in the\nlatest merge. For example, branch A and B of the same project each\nhave 10 commits from the branching point. If a merge A -> B does\ncommits 1,2,3,7,8 it gets imported to git as a merge up to commit \"3\",\nalthough there is more there. The next merge, which does 4,5,6,10 will\nshow up as a merge of commit 8.\n\nYuk. \n\nIf I remember correctly, Junio added some stuff in the merge & rebase\ncode that will identify if a particular patch has been seen and\napplied, and skip it even if it's a bit out of order. But I don't know\nwhat that is based on, and whether I can somehow maximize the chances\nof the patch being identified as already merged across branches. If\nit's based on the initial commit identifier being carried through\n(does that travel with commits when you merge?) I stand a small\nchance. Otherwise, I'm lost.\n\nSuggestions? \n\ncheers,\n\n\nmartin\n"},{"id":"7551","messageId":"7vslx61i3s.fsf@assigned-by-dhcp.cox.net","threadId":"1588","inReplyTo":"46a038f9050819000417ed436e@mail.gmail.com","subject":"Re: [RFC] Importing from a patch-oriented SCM","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-19T07:49:43Z","receivedAt":"2005-08-19T07:49:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff writes:\n\n> If I remember correctly, Junio added some stuff in the merge & rebase\n> code that will identify if a particular patch has been seen and\n> applied, and skip it even if it's a bit out of order. But I don't know\n\nI think you are talking about git-patch-id.\n\nf97672225b3b1a2ca57cfc16f49239bed1efcd87\nAuthor: Linus Torvalds \nDate: Thu Jun 23 15:06:04 2005 -0700\n\n Add \"git-patch-id\" program to generate patch ID's.\n\n A \"patch ID\" is nothing but a SHA1 of the diff associated\n with a patch, with whitespace and line numbers ignored. As\n such, it's \"reasonably stable\", but at the same time also\n reasonably unique, ie two patches that have the same \"patch\n ID\" are almost guaranteed to be the same thing.\n\n IOW, you can use this thing to look for likely duplicate\n commits.\n"},{"id":"7555","messageId":"Pine.LNX.4.63.0508191023570.11916@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1588","inReplyTo":"46a038f9050819000417ed436e@mail.gmail.com","subject":"Re: [RFC] Importing from a patch-oriented SCM","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-19T08:29:40Z","receivedAt":"2005-08-19T08:29:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 19 Aug 2005, Martin Langhoff wrote:\n\n> Each patchset has a unique identifier, and can carry metadata with the\n> identifiers of the patches it \"includes\". If you are using gnu arch,\n> when you merge across branches, it'll know to skip a particular\n> patchset if it has been applied already. AFAICT there is no such\n> concept in GIT, and I wonder what to do with all this metadata about\n> merges.\n\nYou should include the metadata in the commit object. If the information \nis about parents, they should be parents in git, too. If the information \nis something else, you should convert it to readable text and put it in \nthe comment part of the commit object.\n\n> If I remember correctly, Junio added some stuff in the merge & rebase\n> code that will identify if a particular patch has been seen and\n> applied, and skip it even if it's a bit out of order.\n\nThe usual way of git is to use a 3-way merge: given a common ancestor, try \nto apply the changes between the ancestor and the second branch to the \nfirst branch. And yes, this does not take history into account. \nOriginally, I wanted to write an \"intelligent\" merge, which turns the \nhistory into patches and tries to merge these, but ultimately I got \nconvinced that this is too complicated to be worthwhile.\n\nCiao,\nDscho\n"},{"id":"7556","messageId":"46a038f905081901521296c24@mail.gmail.com","threadId":"1588","inReplyTo":"7vslx61i3s.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Importing from a patch-oriented SCM","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-19T08:52:45Z","receivedAt":"2005-08-19T08:52:45Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/19/05, Junio C Hamano wrote:\n> Martin Langhoff writes:\n> \n> > If I remember correctly, Junio added some stuff in the merge & rebase\n> > code that will identify if a particular patch has been seen and\n> > applied, and skip it even if it's a bit out of order. But I don't know\n> \n> I think you are talking about git-patch-id.\n\nIs this used at commit time, and stored somewhere (doesn't seem to be)\nor do you select older patches from the destination branch at merge\ntime?\n\nIf you only compare patches since the last merge, patches that were\nmerged but somehow unreported will fall into a black hole and cause a\nconflict going forward anyway. Hmm. That seems to be a problem I\nwon't be able to avoid if merges happen out-of-order.\n\nI'll try and work out how it's being used during the merge\n(pointers/hints welcome) and see if I can do something smart w it.\nThanks!\n\ncheers,\n\n\nmartin\n"},{"id":"7566","messageId":"Pine.LNX.4.63.0508191141570.23242@iabervon.org","threadId":"1588","inReplyTo":"46a038f905081901521296c24@mail.gmail.com","subject":"Re: [RFC] Importing from a patch-oriented SCM","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-19T16:22:29Z","receivedAt":"2005-08-19T16:22:29Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 19 Aug 2005, Martin Langhoff wrote:\n\n> On 8/19/05, Junio C Hamano wrote:\n> > Martin Langhoff writes:\n> >\n> > > If I remember correctly, Junio added some stuff in the merge & rebase\n> > > code that will identify if a particular patch has been seen and\n> > > applied, and skip it even if it's a bit out of order. But I don't know\n> >\n> > I think you are talking about git-patch-id.\n>\n> Is this used at commit time, and stored somewhere (doesn't seem to be)\n> or do you select older patches from the destination branch at merge\n> time?\n\nIf a patch is applied verbatim, or a merge results in no conflicts (i.e.,\nonly offsets), then you can run git-patch-id on the diff caused by it and\ncompare the result with the git-patch-id of the diff caused by your local\nchange to see if you've found it. Of course, if there was any modification\nto the patch or a conflict was resolved, you won't see a match, but that's\nplausibly correct anyway: you don't know whether the content change that\nresulted from your patch really matched the change you wanted to make.\n\n> If you only compare patches since the last merge, patches that were\n> merged but somehow unreported will fall into a black hole and cause a\n> conflict going forward anyway. Hmm. That seems to be a problem I\n> won't be able to avoid if merges happen out-of-order.\n\nThey might cause conflicts, but they're relatively unlikely to require\nmanual intervention, because the merging mechanism in git is stronger than\nthe one in arch (by virtue of identifying a common ancestor), and will\nrecognize when a section of changes made by both sides is the same and\nproduce a warning rather than a conflict. That's how the rebase stuff can\nidentify that your rebased patch is empty (when upstream applies your\npatch): the content change that it would make has been made.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}