5

I've found a GitHub project I'd like to add some features to. After contacting the maintainer, the changes aren't in line with the direction he's going but he's interested to see what I do with it. What is the GitHub etiquette for using one repo as a base for another project that almost certainly won't ever be merged back into the original?

Instead of forking, my instinct is to create a brand new repo and manually copy the current state of the original code into it. Then, in the documentation, give credit and a link to the original author/repo for the starting point.

Is that acceptable, or is there some other standard approach?

Improve this question
5
  • Great question. IMO Github's support of these kinds of things is a little primitive. – Dogweather Jan 6 '14 at 1:07
  • 3
    why not fork, even if today it doesn't look like merge would ever happen? Doesn't mean original author won't change his mind next week. I've always been under impression that GitHub actively encourages people to build on each others work and fork was their primary mechanism for doing that. – DXM Jan 6 '14 at 3:11
  • 1
    Like @DXM I do not see a reason why forking would not be good. Still, I am curious to know what are your considerations to seek different approach? – Ivaylo Slavov Jan 6 '14 at 7:36
  • There is nothing that you gain from doing it the way you suggested, but you lose a lot of comfort. – Wilbert Jan 6 '14 at 11:27
  • 1
    @IvayloSlavov - I really like the jekyll/mercenary project for a foundation for command line ruby tools. I want it to also process config files. After talking with the maintainer of the original project he doesn't want to add that in order to keep the project light. Per the answers of to this question, I've forked a copy and renamed it to mercenary_plus. I'll let the maintainer of the other project know and if he ever changes his mind I'll ship my code back over. – Alan W. Smith Jan 8 '14 at 2:17
5

Fork. Even if the original repo's author never accept your changes, it is still very likely you will want to pull their updates, and having the original repo as upstream will make this easier.

Improve this answer
1
  • Note: I've found a case where forking doesn't completely work. Without doing some shuffling, GitHub only allows one for of a project. In my case, I'm contributing to the main project but also created my own repo for the code that I want to take off in another direction. – Alan W. Smith Jan 15 '14 at 16:03
3

I would just fork the project and make the the changes I find useful. Then I would make a pull request to original project. The maintainer can then decide to merge your request or not. At this point the link between your fork and the original project is clear. Any users of the original project will be able to find your ideas/changes and might even prefer to use your fork and this might then convince the original maintainer to accept your change in the future.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.