Re: how to add a (history-laden) subdirectory into a repo?

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 13, 2019, 18:47 UTC
Message-ID: <xmqqblsckqpd.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <alpine.LFD.2.21.1912130447510.5127@localhost.localdomain>

"Robert P. J. Day" <rpjday@crashcourse.ca> writes:

Show 33 quoted lines

>   I have a xilinx petalinux (vendor) repo that i started from scratch,
> with a certain amount of history that I would like to hang onto --
> assume the top-level structure (as created by the petalinux-create
> tool) is:
>
>   board_name/
>     dir1/
>     dir2/
>     ... etc etc ...
>
> and so on, and so on. that is the structure of my current repo,
> totally isolated from other content.
>
>   Now, at this client site, they're using petalinux, but their
> existing repository buried the petalinux project content inside a
> larger build infrastructure that involves docker and other tools, so
> the client's single repo has the structure:
>
>   client_repo/
>     blah1/
>     blah2/
>       woof1/
>       woof2/
>       board_name/      <---- subdir content in client repo
>         dir1/
>         dir2/
>         ... etc etc ...
>
> ...
>   I'd like to add my PL repo into that structure -- as you can see,
> all my commits will be relative to the dir structure "board_name/",
> while the corresponding content in the client repo will be relative to
> "client_repo/blah2/woof2/board_name/".

I think that pretending your history were all touching paths with client_repo/brah2/ prefixed to them so that the shape of the working tree resembles with each other is the easiest part of the problem. You could filter-branch or filter-repo your history or even create a fast-export stream and munge paths in it before running fast-import on the result.

A much bigger issue is what you want to record as the result of such a merge. Your client repository may have their own changes they want to keep, and your repository (with paths appropriately munged to match) would also have your changes you want to keep. Obviously there won't be any common ancestor between these two histories, as they evolved independently without being aware of the other.

"git merge --allow-unrelated-histories" would give you a chance to record the result of such a merge, but you'd need to sort the conflict out to match your customer needs.