What criteria does Github use to determine whether or not a given PR "has too many changes" for rebase-merging?
I've worked on a refactoring effort recently and after submitting and getting approval in the PR, I got the following message from Github's UI, preventing me from rebase-merging the change:
This branch cannot be rebased due to too many changes
At the time, I had no idea what exactly the limit was, so I split my ~30-commit PR into 2 ~15-commit changes, which made the restriction go away.
I found a question around the same limitation, but it doesn't focus on what these limits are, asking for workarounds instead:
This branch cannot be rebased due to too many changes
I'm now doing another change which also has a similar number of commits and wanted to know exactly what rules Github uses to determine whether or not a given PR "has too many changes" so that I can split my PRs accordingly upfront and avoid rework both on my end as well as on reviewer's.
I tried finding official documentation on this to no avail. Unfortunately, the only way I'm aware of to test it is to submit the PR and check if the message comes up. This however becomes unfeasible since the message only shows after all checks have succeeded, meaning I have to also get actual reviews on the change to check whether they are mergeable or not. If I then find out it is not mergeable, I have to create a separate PR and split the change, wasting everybody's time on re-reviews.
Many different aspects (or a combination of multiple aspects) could be the cause for this:
Number of commits
Number of affected files
Number of affected lines
Number of conflicts with base branch
etc
I've been using GH for a long time and had never seen this message until a couple weeks ago, so I assume it is either some new feature, or maybe a restriction depending on the type of plan used by my company.
This is almost certainly a timeout-based situation. GitHub uses libgit2 to perform rebases and how long a rebase takes depends on the number of commits, the complexity of the changes in each of those commits, and the complexity related to the repository (size of objects that must be looked up, etc.). libgit2 doesn't have all the optimizations of regular Git, but regular Git cannot rebase in a bare repository, so the use of libgit2 is required.
So there's no fixed limit in the number of commits or the complexity, only that if it takes longer than whatever the timeout is, the operation will fail, and you'll be left with that message. One way to avoid this is to use regular merge commits, which while not immune from timing out, are less likely to do so because the merge involves only three commits, not however many are in your branch.
Related
I know github generally has a rule where PR's and stuff can be closed, but never deleted to preserve history, unless there is something very necessary about it (such as private keys being included in the PR by accident, etc.). I was wondering, however, if draft PR's can be deleted. Sometimes I use it for certain CI/CD testing, and I end up closing them, but they can start cluttering up my PR history. Since they were never converted to a full, real PR, is that a thing we can do without contacting github support?
Thanks!
Apparently no. Draft PRs are treated like regular PRs and cannot be deleted without contacting support. https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository. They only delete them if there is sensitive data.
You might want to setup a separate repo just for CI/CD testing if you are trying to test configurations like Actions. That would keep your main repo from getting cluttered.
If you are creating draft PRs to run tests, that could indicate your tests are difficult (or slow) to run locally. I'm just assuming though. I know that's why I sometimes reply on CI/CD instead of local testing.
Using Github webhooks, what is the best way to count the number of commits by a developer for a particular piece of work.
I was thinking that I could do like this:
Listen for webhooks pertaining to merges of any PR into the main branch
discard the webhook event unless it pertains to the main branch
if the PR merge is into the main branch, then find out all the commits (and developer-related to each commit) related to that merge and calculate a count
are all these commits(and developer usernames) even listed in the webhook event?
Will the commits related to the merge definitely only be comprised of commits after the branch was created up until its merge.. or will they actually go all the way back to the beginning of repository creation?
Had also considered listening on webhooks related to "Tag" type pushes, but would a new tag event be able to tell me about all the commits between that tag and a previous tag.. probably not right? I'm guessing that whatever the tag is that it would always represent all commits from the start of repo creation
You can use roughly the approach you've outlined. You can extract the base and head revisions from the desired webhook events and then run git rev-list --no-commit-header --format=%aE $base...$head to find the email address associated with each commit. (You can use git log instead of git rev-list --no-commit-header if you're using an older Git).
That will count only the commits that were created in the branch and are not otherwise merged into main. Note that if you're using squash merges, this doesn't work because the merge base doesn't update; I recommend not using squash merges anyway. In the case of a squash merge, the number of commits created is always 1. You can tell whether a squash merge has taken place because git merge-base --is-ancestor $head main will exit 1; that is, the head of the PR branch is not an ancestor of the most recent main.
While this will work to count the commits per developer, I should point out that counting a developer's commits is not a good measure of productivity and shouldn't be used as a performance metric. A developer may be highly skilled and write only a single commit after investigating a difficult problem, but counting commits would rank that person lower than someone who fixes many easy problems. There are also other skills, like communication and collaboration, which cannot be measured in commits.
What is the best practice (and why) on closing tickets/issues in the versioning/ticketing system during software development?
Our workflow is based on creating FEATURE or PATCH branches to implement changes and then merge into a controlled master that is (mostly) guaranteed to build and be ready for deployment.
Our ticket system holds bug reports or feature requests we subsequently fix/implement in said branches, then merge into master before the next release.
Which solution is better:
A. Close the ticket once the solution is implemented (and verified) in the FEATURE/PATCH branch. This cleans out the list of open tickets fast and gives a good overview off how much work is left for the next release.
B. Keep it open until the branch has been merged to master and verified there.
Only master represents the final product, so technically only now the work is done. And no bug might stay un-fixed because someone forgot the merge.
My experience is that a support ticket with a feature request is closed after the request is logged with the Product Manager, they acknowledge with a time-frame and the customer has been suitably advised.
For a patch, both are valid approaches, but depending on when the fix is liable to be applied. If it's liable to be a fix-pack release within two weeks: keep the ticket open until the patch is deployed to that customer. Use the ticket as the root for the change management system. Otherwise, if the fix will not be deployed until some future routine release, then my advice is to let the customer know accordingly, and close the ticket.
I'm quite new to GitHub and I'm not sure how I should behave about the number of pull requests I send to a certain project.
Is there such a thing as too many or too frequent pull requests?
Are there general guidelines to follow?
The naming convention for a pull request is your own to make.
The idea is to make a small coherent change that can easily be merged back and tested.
By "coherent", I mean "which introduces only one change or new feature".
It is best to isolate that change in its own branch, that you will push to your fork, and from which you open a new PR: see "couple of tips for PR".
You usually should have one pull request per issue. You should also squash your pull requests to a single commit. Your commit message should be very specific.
Suppose I have a following situation. Long ago I published some useful code on Github and a lot of people forked it since then. Now I find some really serious error (like a buffer overrun) in my code and fix it and I realize that all forks should better have that fix, otherwise Bad Things™ might happen.
How do I notify owners of all forks that there's this critical change they'd better pull?
An upstream repo doesn't really know about its downstream repo (see "Definition of “downstream” and “upstream”").
And you cannot make a pull request to a fork (that wouldn't scale well anyway).
So the easiest was is to count on the other developers to update their local clone with your latest changes, which will include your latest fixes.
You can update your README.md for all to see, but you cannot really "broadcast" to all the forks (not to mention all the direct clones you have no knowledge about).
Anyway, if they want to contribute back, you will reject any pull request which isn't fast-forward.
That means they will have to rebase their work on top of the latest from "upstream" (your repo), before pushing to their fork and making said pull request.