Github search PRS by merge date - github

Is there any way to find PRs in github by it's merge date? Actually the PRs that were merged in the range of the dates.
Didn't find any and it feels weird, so asking the community.
Thanks


There does not seem to be a way to query by date, by "merge_at" field date on a PR using the PR GitHub API.
You can see how a script like file-suggest_backports-py-L333 (python) does it in order to get and sort PR by date.
# Now get all PRs and filter by whether or not they belong to the
# milestone; requesting them all at once is still faster than
# requesting one at a time. This would also be easier if the API
# supported sorting on PR lists
for pr in self.iter_pull_requests(state='closed'):
if (pr['number'] not in milestone_issues or not pr['merged_at']):
continue
merge_commit = self.get_pull_request_merge_commit(pr['number'])
# Ignore commits that were merged before the last tag date
if merge_commit['commit']['committer']['date'] < last_tag_date:
continue
if not self.find_merged_commit(merge_commit,
since=last_tag_date):
yield pr, merge_commit['sha']
But in short, you need to script it:
find the right branches (like the one already merged into master, either because they were merged, or because they have no commit: see "How can I know in git if a branch has been already merged into master?")
delete them both in your local repo and remotely. See "How to delete a Git branch both locally and remotely?"


You can also use github website to do the search by merge time according to the docs: https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests#search-by-when-a-pull-request-was-merged
You can filter pull requests based on when they were merged, using the merged qualifier.
This qualifier takes a date as its parameter. Date formatting must follow the ISO8601 standard, which is YYYY-MM-DD (year-month-day). You can also add optional time information THH:MM:SS+00:00 after the date, to search by the hour, minute, and second. That's T, followed by HH:MM:SS (hour-minutes-seconds), and a UTC offset (+00:00).
with an example as follows:
language:javascript merged:<2011-01-01 matches pull requests in JavaScript repositories that were merged before 2011.

Related

How do I prevent branch merge for bitbucket or github in a specific time range?

for example, I don't want any merge happen in Friday. Are there any rules to apply these mandatory restrictions rather than manual judgment?

github get users merged lines of code from a specific date range

I have been searching Github documentation well as pygithub documentation as well on how I could get the stats for each users committed and merged lines of code into the master branch from a specific date. So far the best i could find is under contributions it list out a users committed lines of codes however this gives the stats for the life of the project but i need to filter this by a specific date. Is there anyway to do this appreciate the help.

It looks like you can pretty easily retrieve a list of the commits from a specific user and in agiven date range using the pygithub Repository get_commits method. You can see from the method signature below that you can filter by the hash, path, date range, and author.
def get_commits(
self,
sha=github.GithubObject.NotSet,
path=github.GithubObject.NotSet,
since=github.GithubObject.NotSet,
until=github.GithubObject.NotSet,
author=github.GithubObject.NotSet,
)

Get commit count for each day along with date along in GitHub API

I am writing Node API to extract data from Github repo.
While doing so, I find a need to count commit for a repo for each day along with date.
I have tried this github api doc
I don't want to do this in this way
https://developer.github.com/v3/repos/commits/
An alternative way of doing this can be is to follow this link down below , but this also do not provide date along with week.
weekly commit count
Any thought/suggestion/help would be appreciated.
Thanks

This might help you:
Git commit count a day
https://www.commandlinefu.com/commands/view/12099/number-of-commits-per-day-in-a-git-repository

Github API: Finding untagged commits

Is it possible to find all untagged commits since the latest release using Github API?

First, you can get the latest release with the GitHub API (which matches the matest tag)
GET /repos/:owner/:repo/releases/latest
That means you can then compare two commits:
GET /repos/:owner/:repo/compare/:base...:head
For example: https://api.github.com/repos/git-for-windows/git/compare/v2.4.5.windows.1...master
Notes:
See Working with large comparisons:
The response will include a comparison of up to 250 commits.
If you are working with a larger commit range, you can use the Commit List API to enumerate all commits in the range.
This assume your release was done on the master branch (but you can create a release on another branch)

How commits are kept in order

Quick question on Mercurial. Suppose my colleague and I both have an up to date copy of trunk. We both make changes, then we both push/pull the changes from each other.
I am guessing Mercurial keeps the changes in order based on the date of the commit (since there is no incrementing revision, just a GUID). So what happens if my computer's date is one day behind and I commit half a day after my colleague. Would my change show up half a day before my colleague's?

#Martijn has your correct answer, but it doesn't seem to be clicking. If this makes anything clear pick his:
The commit times on Mercurial changesets have absolutely nothing to do with how they're merged, interleaved, or combined
Mercurial, and other DVCs, do all history tracking based entirely on the DAG (Directed Acyclic Graph), which means:
the only piece of metadata that matters is the parent or parents of a changeset
Before you commit you can see what the parent of your changeset is going to be by typing hg parents and once you commit you can see it in the hg log.
In your examples if you've pulled your colleague's changesets and updated your working directory to reflect them (hg pull ; hg update) then his or her changeset will be the parent of your changeset. If you haven't pulled/updated to reflect his or her changeset then both of your changesets will have the same parent -- they'll be siblings -- when when they're merged neither will take precedence over the other in any way.
The ordering when you do a hg log is determined by the order in which the changeset arrived in your local repository, and can differ from repo to repo depending on where they've pulled from first -- that's why you can't use the integer numbers shown next to changesets for cross-repo operations -- only the hash is global.
In short the date is never consulted in normal operations and is purely metadata with no more relevance than the author or commit description.

Indeed, your changesets are timestamped (internally stored as seconds-since-the-UNIX-epoch and a timezone offset), and when displaying changeset, they are ordered by timestamp and your changesets will be displayed in the incorrect place as their timestamps are be incorrect. See https://www.mercurial-scm.org/wiki/ChangeSet
This is not really that much of a problem though; timestamps have no bearing on how your changes are merged with those of your colleague. Only the changeset IDs matter here and when merging a common ancestor is used. It'll follow the graph of your changesets down looking for a changeset ID that your colleague also has and then merges your and his changes from the on forward. See https://www.mercurial-scm.org/wiki/Merge
So, merges are not affected, only the display of changesets, where your changesets will be sorted into the wrong location. It'll confuse you and your colleague, but your changes themselves are safe.

The order of changesets is not affected by the timestamp in the changesets. The order is determined solely by the order in which the changesets were created in your local repository.
Mercurial has an append-only architecture so when you pull from another repository, the changesets you pull in are placed after your own changesets, regardless of the timestamps in the new changesets.
The revision numbers (the local integer counter) is just a counter: each new changeset gets the next available revision number. The simple range operator in Mercurial works directly on revisions numbers, and so X:Y means "give me changesets with revision numbers from X to Y (inclusive)". This is not so useful when the revision numbers are based only on the order in which changesets were created or pulled into a repository.
Use X::Y instead, that gives you changesets that are descendants of X and ancestors of Y, i.e., it follows the branches in the history.