Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
repo
-
Large pull requests slow down development
Ohhh yeah. My workflow is:
1. I open a branch. i.e. `ID-XXXX-branch_name-working`.
2. I start coding.
3. I make a ton of quick tiny commits. (I generally label these commits "NO-MERGE: ").
4. I make a bunch of changes.
5. I finally get everything done.
6. I now create a new branch `ID-XXXX-branch_name` from `ID-XXXX-branch_name-working`.
7. I rebase that branch to get my code cleanly formatted by commit with each discrete feature or change getting its own commit.
8. My code goes up for review.
9. I get changes requested.
10. I make a new branch `ID-XXXX-branch_name-v2-working` from `ID-XXXX-branch_name`.
11. I make the requested changes as a bunch of new small "NO-MERGE: " commits.
12. I am now ready for re-review.
13. I now create a new branch `ID-XXXX-branch_name-v2` from `ID-XXXX-branch_name-v2-working`.
14. I rebase those NO-MERGE changes into my "presentable" commits, adding or removing well documented commits as necessary.
15. I now send out my v2 revision to the mailing list or I change the HEAD of my PR from `ID-XXXX-branch_name` to `ID-XXXX-branch_name-v2`. If I'm using a PR workflow, I link a diff between the two revision branches (you can do this in github using `https://github.com/org/repo/compare`). That isn't necessary with patchsets since I can easily do a range diff there. I suppose I could do a cover letter with range diff and paste it to github but it somehow doesn't seem as nice.
16. Rinse repeat steps 8-15 as necessary for each new revision.
17. "LGTM"
18. Merge into `main`/`master` (like actual merge, not rebase or squash merge) and close PR.
19. Clean up branches. Either save them somewhere for prosperity if you have trust issues like me or just delete them.
This looks like a lot but I was trying to be as detailed about that workflow as I can be. Realistically it's not so bad and you can get a hold of it very quickly.
Also with regards to rebasing changes into well documented, discrete commits, if when you are doing your development you make your commits small and self contained, with `git rebase -i` you can actually just reorder the list of commits to chunk together the related commits and 99% of the time it'll rebase with little to no merge conflicts. Then you can just squash those chunks down into your presentable commits. This also applies to your v2 changes and on. You can just move those commits in the rebase TODO to put them after the commit you want to squash/fixup them into and if they are small clean changes, they should rebase without conflict. Things only get nasty and break when your commits are spanning multiple unrelated files and you try to break those up.
I'd estimate rebasing new changes into an already documented set of commits probably takes me 1-2 minutes on average so I consider it well worth the extra 30 minutes spent over the course of the week.
-
Style Your RSS Feed
I use Atom feeds for Github release / tag notification. The format is:
https://github.com/org/repo/tags.atom
-
How do you track software updates?
if anyone wants to use the GH RSS feed https://github.com/org/repo/releases.atom
-
Nudge Github PR reviewers with Slack API
@match https://github.com//*/pull/* to run the script only when navigating to a PR page, such as https://github.com/Org/Repo/pull/4605
-
Hoe to download release artifacts through curl
curl -o ~/demo.jar https://github.com/org/repo/releases/download/v0.2/demo-0.2.jar
jordemort
-
Style Your RSS Feed
I do this both on my RSS feed: https://jordemort.dev/rss.xml
...as well as on my Atom feed: https://jordemort.dev/atom.xml
...using the same XSLT stylesheet for both: https://github.com/jordemort/jordemort.github.io/blob/main/p...
What are some alternatives?
sniprun - A neovim plugin to run lines/blocs of code (independently of the rest of the file), supporting multiples languages
PHPT - The PHP Interpreter
SemanticDiff - Community support for SemanticDiff, the programming language aware diff for Visual Studio Code and GitHub.