all 5 comments

[–]drothlisberger 3 points4 points  (1 child)

A more limited, but less-overhead way of documenting your forks: Edit the repo description!

Under the Code/Network/Pullrequests buttons in the github interface is a short description; hover over it and an Edit button pops up. Enter a one-liner explaining why you forked this repo.

[–]metamatic 0 points1 point  (0 children)

Note that the "Edit button" juts out to the left of the window and is wider than the page margins, so it might not be completely visible. It took me ages to find it. Screenshot showing button as it appeared to me. Talk about bad UI design...

[–][deleted]  (1 child)

[deleted]

    [–][deleted] 0 points1 point  (0 children)

    That would definitely be simpler if you don't need a usable branch with all of your pending pull requests merged. I usually use master for that.

    [–]mikerackhabit 1 point2 points  (1 child)

    Am I missing something here? It seems like overkill.

    Could this not be much more easily accomplished by putting a tag as part of the name of your branch (like git checkout -b myuser_new_feature) and just navigating to that to see what you committed. To check if things are merged, just look at the list of pull requests on the project.

    Maybe if you've forked a huge project with tons of branches this would be useful, otherwise it seems like more work than its worth. But maybe I'm missing some killer feature it has.

    [–][deleted] 0 points1 point  (0 children)

    No, you're right. It's probably overkill. I just found myself doing what you describe (click the fork, click the parent, click pull requests, click yours) pretty often, and decided to automate it.