2

image that another Open-Source project on Github provides some parts that I would like to reuse in my project, like

  • a few stylesheets,
  • a CSS,
  • a small module, or
  • a LaTeX template.

All I need is a small subset of the other project. Often the scope and functionality of the other project is very far from mine.

What will be the best way to organize this from a practical (assuming the legal perspective is covered by the existing license)? Ideally, merging improvements from the upstream repository and sending pull requests for local improvements I create back to the original project would remain possible.

a) I could add the other Github repository to the requirements.txt of my project, install it and optionally delete all the parts that I do not need after installation in my installation procedure (setup.py etc.). b) I could fork the other Github repository, reduce my fork thereof to the files I need, and add my fork to the requirements of my new project.

I found Linking a single file from another git repository, but his does not really address my needs.

Of course, it is risky to establish a rigid link to the internal organization of another project. But that is not the issue in here.

Any ideas?

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
Martin Hepp
  • 1,380
  • 12
  • 20

1 Answers1

2

If you really need to keep a strong link between some files of a repository and your own project repo, I would:

  • add a fork of the first repository as a submodule inside my own project repository
  • use symlinks inside my project for the few files I need (symlink to the submodule required file)

That way:

  • I can use those files anywhere inside my project
  • each time I modify them, I actually change their content in the submodule repository, which makes it easier to identify the change, and make a pull request
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks! In the setup script of my main project, I could also delete all parts that are not needed from the locally installed version (not from the repository). As long as one is careful to not remove them also from the fork in the repository, one could still commit changes to the fork and trigger a pull request to the upstream repository of the official project. Or even modify the .gitignore respectively and exclude it from git itself. – Martin Hepp Mar 09 '21 at 00:17
  • 1
    @VonC what if i have a project repo where i want to PR a few files or dir from to a much larger library repo(~12GB) owned by someone else? they are not using submodules. im not sure of a git flow that would work in this case other than just manually copying the desired files/dir from my project repo to a fork of theirs, and making the PR that way. – kinghat Apr 13 '22 at 16:50
  • 2
    @kinghat A PR is suppposed to be done from a fork, which is a clone of the full repository. However, you don't have to clone the full repository. You can [filter and sparse checkout what you clone](https://stackoverflow.com/a/52916879/6309). – VonC Apr 13 '22 at 22:22