1

I am working on a private repository A that extends and builds on some earlier work I put into a public repository B. However, A already contains a lot of work not coming from B, so that I would like to copy B into a subdirectory of A (let's call this copy B').

Requirements:

  • The public repository B must remain in the state it is because that serves for future reference. It may develop further, but this development will not be synchronized with A.
  • The private repository A must maintain the history of the public repository B. A will remain private for the foreseeable future.
  • B', the copy of B within A will continuously evolve, but over time diverge substantially from B, also because its use within A follows different requirements.
  • B' must maintain private. It should not be pushed into or synchronized with B.
  • B must remain public, it must maintain its history and the links with its public forks.

I am aware of git submodule. However, I do not intend to synchronize with the public repository after the fork. In particular, changes to B' will be proprietary. In my understanding, changes within a submodule will normally have the same visibility as the original content of the submodule, so that would not work in my case.

NB: Similar questions:

Their gist: Use submodule. Is there any alternative?

The only idea I had so far was to revoke the visibility of B to private and put a fresh copy into a new repository with the same URL, but that would detach existing public forks of B and probably kill the history of B.

Chiarcos
  • 324
  • 1
  • 10
  • I guess a possible solution is the one sketched under https://stackoverflow.com/questions/44777043/git-copy-history-of-file-from-one-repository-to-another. However, this thread is almost 5 years old and rather laboursome. Maybe, there is a more convenient way of doing things today. – Chiarcos Jul 28 '21 at 14:32
  • History is commits; commits are the history. Keep the original commits and you have the history. That's all there really is to it. The big problem is, you often have good reason you don't *want* the *original* commits, and that's where all the complications set in. – torek Jul 29 '21 at 02:33
  • @sk_pleasant-EliasHolzmann: Yes, that's what I've been looking for. I felt I was overlooking something obvious. I had ruled out subtree earlier, but I had different requirements, then, so I didn't consider it at this point. – Chiarcos Jul 29 '21 at 09:27

0 Answers0