{"thread":{"id":"52446","subject":"how to add a (history-laden) subdirectory into a repo?","startedAt":"2019-12-13T10:26:47Z","lastAt":"2019-12-13T20:40:44Z","messageCount":3,"participants":["Robert P. J. Day","Elijah Newren","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"388102","messageId":"alpine.LFD.2.21.1912130447510.5127@localhost.localdomain","threadId":"52446","inReplyTo":null,"subject":"how to add a (history-laden) subdirectory into a repo?","fromName":"Robert P. J. Day","fromEmail":"rpjday@crashcourse.ca","sentAt":"2019-12-13T10:00:33Z","receivedAt":"2019-12-13T10:26:47Z","isPatch":false,"sender":{"key":"rpjday@crashcourse.ca","avatar":"https://avatars.githubusercontent.com/u/226084077?v=4"},"body":"\n  (i suspect there's an easy solution -- possibly involving\nfilter-branch or elijah newren's git-filter-repo, or possibly\nsomething even simpler, so let me try to be brief.)\n\n  i have a xilinx petalinux (vendor) repo that i started from scratch,\nwith a certain amount of history that i would like to hang onto --\nassume the top-level structure (as created by the petalinux-create\ntool) is:\n\n  board_name/\n    dir1/\n    dir2/\n    ... etc etc ...\n\nand so on, and so on. that is the structure of my current repo,\ntotally isolated from other content.\n\n  now, at this client site, they're using petalinux, but their\nexisting repository buried the petalinux project content inside a\nlarger build infrastructure that involves docker and other tools, so\nthe client's single repo has the structure:\n\n  client_repo/\n    blah1/\n    blah2/\n      woof1/\n      woof2/\n      board_name/      <---- subdir content in client repo\n        dir1/\n        dir2/\n        ... etc etc ...\n\nfrom my perspective, the ideal solution would have been for the client\nto develop its build infrastructure, and include the PL project as a\nsubmodule or subtree, as that content really is independent from the\nbuild infrastructure but, for whatever reason, the above is all just\none honking big repo with commits to the build content intermixed with\ncontent related to the PL project.\n\n  i'd like to add my PL repo into that structure -- as you can see,\nall my commits will be relative to the dir structure \"board_name/\",\nwhile the corresponding content in the client repo will be relative to\n\"client_repo/blah2/woof2/board_name/\".\n\n  if submodules or subtrees are not an option, what is the easiest way\nto insert my content into the appropriate subdirectory in the client\nrepo, while retaining my history? i'm sure there's a simple way to do\nthis, it just escapes me at the moment.\n\nrday\n\n-- \n\n========================================================================\nRobert P. J. Day                                 Ottawa, Ontario, CANADA\n                         http://crashcourse.ca\n\nTwitter:                                       http://twitter.com/rpjday\nLinkedIn:                               http://ca.linkedin.com/in/rpjday\n========================================================================\n"},{"id":"388125","messageId":"CABPp-BEke9YSUp=DDS6jZCk0z6SR64FMv5nLCLoJDE=52d8MMg@mail.gmail.com","threadId":"52446","inReplyTo":"alpine.LFD.2.21.1912130447510.5127@localhost.localdomain","subject":"Re: how to add a (history-laden) subdirectory into a repo?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-12-13T17:16:54Z","receivedAt":"2019-12-13T20:39:44Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"HI Robert,\n\nOn Fri, Dec 13, 2019 at 2:28 AM Robert P. J. Day <rpjday@crashcourse.ca> wrote:\n>\n>   (i suspect there's an easy solution -- possibly involving\n> filter-branch or elijah newren's git-filter-repo, or possibly\n> something even simpler, so let me try to be brief.)\n>\n>   i have a xilinx petalinux (vendor) repo that i started from scratch,\n> with a certain amount of history that i would like to hang onto --\n> assume the top-level structure (as created by the petalinux-create\n> tool) is:\n>\n>   board_name/\n>     dir1/\n>     dir2/\n>     ... etc etc ...\n>\n> and so on, and so on. that is the structure of my current repo,\n> totally isolated from other content.\n>\n>   now, at this client site, they're using petalinux, but their\n> existing repository buried the petalinux project content inside a\n> larger build infrastructure that involves docker and other tools, so\n> the client's single repo has the structure:\n>\n>   client_repo/\n>     blah1/\n>     blah2/\n>       woof1/\n>       woof2/\n>       board_name/      <---- subdir content in client repo\n>         dir1/\n>         dir2/\n>         ... etc etc ...\n>\n> from my perspective, the ideal solution would have been for the client\n> to develop its build infrastructure, and include the PL project as a\n> submodule or subtree, as that content really is independent from the\n> build infrastructure but, for whatever reason, the above is all just\n> one honking big repo with commits to the build content intermixed with\n> content related to the PL project.\n>\n>   i'd like to add my PL repo into that structure -- as you can see,\n> all my commits will be relative to the dir structure \"board_name/\",\n> while the corresponding content in the client repo will be relative to\n> \"client_repo/blah2/woof2/board_name/\".\n>\n>   if submodules or subtrees are not an option, what is the easiest way\n> to insert my content into the appropriate subdirectory in the client\n> repo, while retaining my history? i'm sure there's a simple way to do\n> this, it just escapes me at the moment.\n\nHi Robert,\n\nI'm still not quite sure what you want, but here's a few possibilities:\n\nIf you want the history of your PL repo kept the same (with everything\nunder \"board_name/\") but for the merge and subsequent commits to have\nthe content at \"client_repo/blah2/woof2/board_name/\", then you just\nfetch the PL repo's history into the other and do a merge using the\nsubtree merge strategy.\n\nIf you want to rewrite the history of your PL repo (so that not only\nnew commits but history has all paths under\n\"client_repo/blah2/woof2/board_name/\"), which will allow people to do\nthings like \"git log -p -- client_repo/blah2/woof2/board_name/\" and\nsee the historical commits from your PL repo, then use filter-repo's\n--to-subdirectory-filter option (\"git filter-repo\n--to-subdirectory-filter client_repo/blah2/woof2\"), and then merge the\nrepos together afterward. (And since the paths now line up, you won't\nneed to use the subtree merge strategy).  Note that I'm assuming\nyou'll just be merging one branch in and not pulling in tags.  If tags\nof the PL repo are important and possibly conflict, you may also want\nto look at the --tag-rename option to filter-repo as well.\n\nIf you not only want paths to line up but want to avoid a big merge\ncommit and instead weave commits together from the two repositories to\npretend they were all in the same repo all along, then I have nothing\nfor you.  There are so many choices and ways to \"weave commits\ntogether\"; I think it'd be a cool thing to do on top of filter-repo,\nbut never came up with anything.  I've got a few ideas, but...they\nsound like too much work and it's really not my itch to scratch.  Or\nat least isn't right now.\n\n\nHope that helps,\nElijah\n"},{"id":"388141","messageId":"xmqqblsckqpd.fsf@gitster-ct.c.googlers.com","threadId":"52446","inReplyTo":"alpine.LFD.2.21.1912130447510.5127@localhost.localdomain","subject":"Re: how to add a (history-laden) subdirectory into a repo?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-12-13T18:47:42Z","receivedAt":"2019-12-13T20:40:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Robert P. J. Day\" <rpjday@crashcourse.ca> writes:\n\n>   I have a xilinx petalinux (vendor) repo that i started from scratch,\n> with a certain amount of history that I would like to hang onto --\n> assume the top-level structure (as created by the petalinux-create\n> tool) is:\n>\n>   board_name/\n>     dir1/\n>     dir2/\n>     ... etc etc ...\n>\n> and so on, and so on. that is the structure of my current repo,\n> totally isolated from other content.\n>\n>   Now, at this client site, they're using petalinux, but their\n> existing repository buried the petalinux project content inside a\n> larger build infrastructure that involves docker and other tools, so\n> the client's single repo has the structure:\n>\n>   client_repo/\n>     blah1/\n>     blah2/\n>       woof1/\n>       woof2/\n>       board_name/      <---- subdir content in client repo\n>         dir1/\n>         dir2/\n>         ... etc etc ...\n>\n> ...\n>   I'd like to add my PL repo into that structure -- as you can see,\n> all my commits will be relative to the dir structure \"board_name/\",\n> while the corresponding content in the client repo will be relative to\n> \"client_repo/blah2/woof2/board_name/\".\n\nI think that pretending your history were all touching paths with\nclient_repo/brah2/ prefixed to them so that the shape of the working\ntree resembles with each other is the easiest part of the problem.\nYou could filter-branch or filter-repo your history or even create a\nfast-export stream and munge paths in it before running fast-import\non the result.\n\nA much bigger issue is what you want to record as the result of such\na merge.  Your client repository may have their own changes they\nwant to keep, and your repository (with paths appropriately munged\nto match) would also have your changes you want to keep.  Obviously\nthere won't be any common ancestor between these two histories, as\nthey evolved independently without being aware of the other.\n\n\"git merge --allow-unrelated-histories\" would give you a chance to\nrecord the result of such a merge, but you'd need to sort the\nconflict out to match your customer needs.\n\n"}]}