Forking a FOSS-project's Git repository

Question

I'm seriously starting to think that I need to fork an open source project, for it to suit my own needs. I've sent patches to the original author, but the responses have been pretty terse and, well, unwelcoming.

Anyhow. I've read the question Forking an open source project nicely, but this doesn't answer my more specific question:

What should I do with the files?

First of all, should I continue with the origninal Git repository, or just throw away all history, and begin anew ("rm -rf .git && git init")? Secondly, are there any opinions regarding old readme:s, previous release info and versioning?

Naturally, licensing and attribution would be handled as per the license's requirements.

Answer 1

If you intend to do a full rewrite, go with a freshly init-ed git. For anything other than that, just do a clone.

Answer 2

History is the most valuable part of source control. I'd say keep the history and just label the point where your own development begins.

Answer 3

1. Fork it from Github
2. CLone it to your local machine
3. Apply the patches you sent the original author that were not accepted
4. Push

Should be pretty painless, and it's the right way to do it unless you are rewriting everything from scratch.

Answer 4

Reasons why I would keep the history:

1. The most important reason: this allows you to import useful changes from the original code as they come in. Unless you predict that your project is going to diverge from the original so thoroughly that you will never want anything they do to appear in yours, it makes it much easier to track down those useful changes and import them.
2. It makes it easier to give back is should you ever want to (say the original project's owner becomes more willing to work with you).
3. It makes it easier to trace the origin of a particular change if you ever look back at it scratching your head wondering what it means. In the case of git it helps you hunt bugs because of git bisect - you may find a change you thought was harmless is actually critical. This is the sort of thing that can be easy to find with bisect and very hard without it. You can't do that without history.

If none of that applies you may want to start fresh. But even if you do, keep the history around in a private copy. If you ever need it you can transplant your changes from your new repository and do all of the above.

Answer 5

If you're actually forking (starting off where the original project left off), definitely clone the original repository and just continue committing. This will not only allow you to merge changes from the original repository, but also let the developers of the original project merge changes back from your fork. If both projects live on Github this collaboration would be even easier (pull requests).

This should actually be quite natural, since you should be making changes in your repository and either sending patches or pull requests. Forking is the same, except it's labelled as a separate project.

Answer 6

As others have pointed out: You should really keep the history. Regarding READMEs and versioning: You should rename your project to avoid any confusion with the original project. You can use a name that alludes to the original project (but be aware of potential trademark issues), but try not to be disrespectful. For example, naming you project "foo-ng" (next generation) if the original project is named "foo" would somehow state that your project is "better" than the other one. Even if you feel this to be the case, don't do that.

READMEs should be updated for your needs. I.e. it should document the new project name, the fact that it is a fork of project "foo" and possibly the point at which it forked. Personally, I would also keep ChangeLogs and similar, more technically-oriented documents and append to them as necessary, but begin fresh any "NEWS"-style document, i.e. documents targeted at end users.

Answer 7

Even if you never plan on sending patches back to the original author, git makes a wonderful local versioning tool as well.

Another cool thing about github, as an addendum to some of the other workflow's posted previously:

1. Create a github account.
2. Fork the repository you want (by going to their page on github and clicking the fork button)
3. Follow the instructions to git clone your new repo locally
4. Work on things locally as desired; also, be sure to pull updates from the original source on github (you can do this from your version of the project on github, in the Fork Queue)
5. (Instead of sending a patch to the original author) Ask the author to grab your patches by going to the Fork Queue page for the original project - it makes it painless for the original author to grab your changes.

If you get crappy responses from authors of projects, then they don't exactly deserve your help and you shouldn't worry too much about giving back, I suppose. However, still follow step #4 about your Fork Queue - you can stay up-to-date with everyone else on github who is making changes to the project along with you.

A quick addition: if you want to keep your work a bit separate from the original authors, it is pretty easy to: * Create a new branch (git checkout -b my_branch_name) and work there.
* Once you have that branch in the state you want, you can switch back to the original branch (git checkout master) and merge your changes back in (git merge my_branch_name).
* Then you can push it back out to github (git push origin master), or * Makeake a patch for the original author (with some version of git format-patch).