0

     Suppose one was trying to merge together a bunch of different GitHub repositories with certain properties. Namely, most of these repositories have contents that are copies of various tarballs mirroring various historic states of an external, read-only repository's working tree.
     However, one of the repositories in question only contains the contents of a folder from inside that working tree. Considering that all of the other repositories share a lot of tarball-dumping commits that updated their contents, could one create a new repository and set it up so that all of the other repositories, even the errant one, end up as forks of it?
     If that is possible, then could the new repository preserve all of the history from the reverse-merged repositories? Even then, though, how would one go about doing such an operation?

RandomDSdevel
  • 431
  • 6
  • 17
  • If you need specifics, I describe the actual merge I'd like to complete [here](http://stackoverflow.com/questions/25922858/how-to-do-a-complicated-git-repository-merger?lq=1). – RandomDSdevel Feb 11 '16 at 01:33
  • You can construct any history you want. It's not hard. `git commit-tree` creates a commit with arbitrary tree, parents and metadata. `git write-tree` constructs the tree for the content in the index; other trees are already in the repo somewhere or can be constructed directly with `git mktree`. – jthill Feb 24 '16 at 05:55
  • @jthill: Do you know of any good tutorials on how to do this in situations like the one I'm in? – RandomDSdevel Mar 15 '16 at 19:15
  • All of git's complexity is in the variety of things you can do with its stunningly simple core structure. I'm not kidding. Do `git init . --template=''` to make a playground repo without breadcrumbs left there for people who've already read a fair amount of doc, and use the `find` command liberally to see just how straightforward git operations really are. That dag-of-trees structure is robust to the point of unbreakability, so don't be afraid to dink around. The individual tarballs are the trees, draw the dags you want and you're done. – jthill Mar 15 '16 at 20:35
  • @jthill: That's all very well and good, but it doesn't help me much since it doesn't do a good job of explaining what Git commands might be useful in the context of this question and how and in what order I might want to use them. Also, I'm not _just_ dealing with pure tarballs here: said archives were copied into _other people's_ Git repositories _first_, and I'm trying to _merge_ all of them, which has proved difficult for me since not all of them mirror the entire history of their non-cloneable source, in such a way that _my_ repository's dependencies on _theirs_ is _inverted._ – RandomDSdevel Mar 21 '16 at 22:09

0 Answers0