1

I have a GitHub repository https://GitHub.com/JohnBurger/Edison.

Inside it there are many subdirectories with modules specific to the Intel® Edison - but some that are more generic. In fact, I now have an Arduino project that could take advantage of some code in that repository, so I thought I'd fork a new repository https://GitHub.com/JohnBurger/Arduino, from Edison. Only, when I try, GitHub simply doesn't do it. I click "Fork", it thinks about it, and then... nothing. I reckon that's because the source is already mine, and I don't get the opportunity to rename the new fork.

I figure what GitHub wants me to do is clone it into a separate local directory, then create a new repo for it and commit it back into the new one - but will that maintain the full history?

Actually, what I really want to do is be selective about which parts of the directory hierarchy to keep and which to jettison (as in, completely remove). For example, say the existing repo looks like this:

Edison/
   Dir1/
   Dir2/
   Dir3/
      SubDir1/
      SubDir2/
   Dir4/

I want a new repo to look like:

Arduino/
   Dir2/          [from Edison]
   Dir3/          [from Edison]
      SubDir2/    [from Edison (note SubDir1 is missing)]
   Dir5/          [new to this Project]

with all of the history of the included directories, but none of the irrelevant baggage from Edison.

Ideal

But, if I'm really wishing I'd actually want a third repo:

General/
   Dir2/
   Dir3/
      SubDir2/

Edison/
   [link to General/]
   Dir1/
   Dir3/
      SubDir1/
   Dir4/

Arduino/
   [link to General/]
   Dir5/

That way:

  • General/ still has all the changes I made while developing Edison/.
  • If I make future changes to anything in General/, then both Edison/ and Arduino/ will benefit.
  • Anyone simply getting either Edison/ or Arduino/ would get the whole shebang, ready to compile.

But I don't know if Git works like that... or if I can still have per-architecture specific branches of certain files within those directories.

If it can, though, could someone please provide the instructions to:

  • Create General/ from Edison/, maintaining history;
  • Remove General/ from Edison/, purging history;
  • Linking General/ into Edison/;
  • Creating Arduino/ and linking General/ into it;
  • How to have architecture-specific versions of files within General/.

That would be ideal, thanks!

0andriy
  • 4,183
  • 1
  • 24
  • 37
John Burger
  • 3,662
  • 1
  • 13
  • 23

2 Answers2

2

That's true, you can't fork your own repository.

If you clone your repository to a new folder and push it to a new repo the history will remain. See this question for details.

git clone https://github.com/yourname/your_repo.git repo_dir
cd repo_dir
git remote rename origin old_origin
git remote add origin https://github.com/yourname/your_repo2
git push origin master
git remote rm old_origin

Actually, a fork is just a copy of the repository with all the history preserved.

To achieve the first option you just need to create a copy of your repository, delete files which you don't need and commit changes back to GitHub.

The second option is a bit more complicated but git supports submodules. And that's what you need.

Have three repos, one Generic, which is used as a submodule for other two.

Links

Community
  • 1
  • 1
Anton Sizikov
  • 9,105
  • 1
  • 28
  • 39
  • Submodules look good! Do you know if they're simply "One directory within the parent", or somehow "Merged as an overlay on top of the existing hierarchy" - as I tried to demonstrate with `Dir3/SubDir1` and `Dir3/SubDir2` above? – John Burger Jun 25 '16 at 12:21
  • this is just a link to another repository (a link to a specific commit of that repository). So on a file system is will look like a copy of `Generic` repository dir structure. – Anton Sizikov Jun 25 '16 at 12:25
  • This is a good answer. But unless you're going to be actively backporting changes to your submodules, then you should consider using a dependency package manager like composer or npm. – Jeff Puckett Jun 25 '16 at 14:18
  • True, I don't recommend using submodules in general, but that's what the OP wants, and as far as I understand the development in common part is going to be active. – Anton Sizikov Jun 25 '16 at 14:24
0

Sounds like a good use case for git submodules.

As for splitting the repo, you might want to look at git filter-branch (some examples: link, link).

tompave
  • 11,952
  • 7
  • 37
  • 63