Need advice regarding fork, copy or something else

[Fran-B]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Body

There is a GitHub repo that I originally just grabbed a copy of for use in by application that I was working on.
I needed only about 10% of its content, so I deleted a lot of directories and renamed a few files. I may have made some minor, non-functional, edits to a couple also. All that was done in my copy local to my machine.

Now I want to publish the application I needed that repo for, and figured that I would fork the original, remake my changes, then depend my application on my fork. Thus others could choose to build my application using my truncated version, or the original version, depending on their needs.
My expectation was that I could then maintain history and pull changes from the parent ,without causing the parent owners any problems or concerns.
I would never think of issuing a pull request, because the other parent content is certainly useful to the wider original intent; it just creates a lot of dependancies to support features that I have no need of.

I recently forked another repo in order to make some changes that I thought useful to the owners of that repo. I then

• Created a branch in my forked repo
• Pushed my changes into that branch.
• Created a Pull-Request intending it to be for moving changes from my branch into my forked repo.

What actually happened is my pull-request went to the original repository owner, and I seem to have lost control over it.

So it now seems to me that a fork would not make sense because it is too tightly coupled to the owner. However, I do need a repo that I can depend upon that does not require a lot of others to support functionality that I do not need. Should I:

1. Actually create the fork, then delete what I do not need?
2. Create a new repo and tie things to the original using its README?
3. Do something else that I have not thought of?

The subject repo is published under a choice of dual licenses and my usage would not violate that.

I definitely want to do the right thing here, but am having trouble knowing what that is. I really need to keep my changes isolated from the original repo. However, it is important to me that somebody wanting to extend my application be able to use the original, in place of my truncated version of it.

Advice and ideas would be appreciated.

[tonderaikawere]

From what you've described, I don't think a fork is necessarily the best fit.

Forks are great when you expect to stay closely aligned with the upstream project, periodically pull in changes, and possibly contribute fixes back. The fact that GitHub naturally encourages pull requests to the upstream repository is part of that workflow, even though you don't have to submit one.

Since your version intentionally removes a large portion of the project and serves a different purpose, I'd lean toward creating a new repository instead. In the README, you can clearly state:

• which project it originated from,
• which version or commit you started with,
• why you've trimmed it down,
• and which license applies.

That keeps your project independent while still giving proper credit and making it easy for others to find the original.

If you still want to bring in upstream bug fixes occasionally, you can add the original repository as an upstream remote in your local Git clone and selectively cherry-pick or merge changes that are relevant, without your GitHub repository having to remain a fork.

One question: when you created the pull request on your other fork, did you change the base repository to your fork, or did you leave it pointing at the upstream project? By default, GitHub often assumes you're proposing changes back to the original repository, but you can change both the base repository and the base branch when opening a PR.

[Fran-B]

To answer your question, "I didn't pay attention".
Since I was creating the pull-request from a branch, I expected the destination was the branch's parent, not its parent.
I now understand that is the default behavior, but it is contrary to what I consider normal git flow. A pull request from a branch should, by default, go to the "parent" of the branch; not skip that to the "parent's parent".

I guess I will see about "breaking" the fork connection when I create that repo.
I think I saw another issue since writing this one that mentioned something about that.