GitHub advanced search default behaviour - github

I'm new to Github and just want to browse through repos to find interesting ones.
I want, say, all ruby repos with more than 100 followers.
I go to advanced search and try "followers:100"
and get only repos with EXACTLY 100 followers (4 at the moment).
That differs from what i expect to be default behavior - find repos with 100 or more followers (more like Stackoverflow search works).
I am quite frustrated, because I can't get what is expected to be basic search functionality from a very popular site, and that makes me think that I'm obviously not understanding something very simple (because I think it is not possible for Github not to have such functions).
So is there a way for me to get the desired result?

Update January 2013 (source: "A whole new code search")
followers:>100
(intervals are supported: followers:100..150)
Original answer (April 2011)
followers:[100 TO *]
should do what you want: see your query with 100 or more followers.
(Note: the "TO" needs to be in uppercase)
(Source: New and Improved Search)
For example, we can search:
for people with a username fuzzily similar to ‘chacon’
who use Ruby as their primary language,
have at least 5 repos and
at least one follower:

You might also like the Hubscovery application. A simple search interface for Github.

Related

How do I search the readme of repositories using Github Search API?

My objective is to count the number of repositories that use PyTorch. Therefore, I came up with the following code, using the THUNDER CLIENT extension in VS Code -
https://api.github.com/search/repositories?q=language:python + readme:PyTorch
However, this gives me just 7 search results. I am confident the result should be in the range of thousands. Could someone suggest where I am going wrong?
The GitHub search API for repositories checks the name, description and the README of all repositories.
Therefore, all that was needed to be done was -
https://api.github.com/search/repositories?q=PyTorch

RESTful urls for restore operation from a trash bin

I've been implementing a RESTful web service which has these operations:
List articles:
GET /articles
Delete articles (which should remove only selected articles to a trash bin):
DELETE /articles
List articles in the trash bin:
GET /trash/articles
I have to implement an operation for restoring "articles" from "/trash/articles" back to "/articles".
And here is the question. Ho do you usually do it? What url do I have to use?
I came up to the 2 ways of doing it. The first is:
DELETE /trash/articles
But it feels strange and a user can read it like "delete it permanently, don't restore".
And the second way is
PUT /trash/articles
Which is more odd and a user will be confused what this operation does.
I'm new to REST, so please advice how you do it normally. I tried to search in google but I don't know how to ask it right, so I didn't get something useful.
Another option could be to use "query params" to define a "complementary action/verb" to cover this "special condition" you have (given that this is not very easily covered by the HTTP verbs). This then could be done for example by:
PUT /trash/articles?restore=true
This would make the URI path still complaint with REST guideline (referring to a resource, and not encoding "actions" - like "restore") and would shift the "extra semantics" of what you want to do (which is a very special situation) to the "query parameter". "Query params" are very commonly used for "filtering" resources in REST, not so much for this kind of situation... but maybe this is a reasonable assumption given your requirements.
I would recommend using
PUT /restore/articles
or
PUT /restore/trash/articles
Late answer but, in my opinion, the best way is to change the resource itself.
For instance:
<article is_in_trash="true">
<title>come title</title>
<body>the article body</body>
<date>1990-01-01</date>
</article>
So, in order to remove the article from Trash, you would simple use PUT an updated version of the article, where is_in_trash="false".

"News System" acting different on different systems

I have 2 servers which I though were synchronized (dev and live) but the "News System" (extension key "news") makes something different.
In the dev server this line
<f:format.date format="%A">{newsItem.datetime}</f:format.date>
outputs "Freitag", as expected (Thats friday in German)
But in the Live Server, it outputs %AM. Which is even weirder is that l (alone, without %) outputs "Friday" in English.
I've checked all the configurations I've seen and I cant seem to find where the difference between the systems is.
Any idea?
TYPO3 is using DateTime::format (http://de2.php.net/manual/en/datetime.format.php) to format the date. This method is using the same syntax of date() which is not using locales, so all output is english.
The only thing I can not explain is why your dev enviroment accepts %A to render the date. Are there different PHP-Versions? Which TYPO3 Version are you using? Get a look at /typo3/sysext/fluid/Classes/ViewHelpers/Format/DateViewHelper.php, you will get the answer there.
I just solved it! Turns out I had 4.7.7 in my live server, and that doesnt support stftime.
Funny, I never thought that such an important feature would be added in an 4.7.X update...

Is there any way to show all GitHub tickets without an assignee?

It seems kinda silly that this feature wouldn't be there. I feel like I am overlooking something obvious, but I haven't been able to Google any answer successfully.
#LyndenShields's answer doesn't seem to work anymore.
At this date (March 16, 2015), the way to search for issues that have no assignee is to use the no: qualifier in the issues Filter field:
no:assignee
Alternatively, you could use the following query string to achieve the same:
https://github.com/<username>/<repo>/issues?q=no%3Aassignee
EDIT: Note that I could not make it work if I only had one qualifier specified (ie. you may need to add another one and have it like no:assignee is:open).
EDIT #2 (March 16, 2016): the above edit is not accurate anymore (hence the strikethrough); GitHub now accepts search queries with one qualifier only.
EDIT #3 (July 26, 2017): removed the %01 from the end of the URL - it basically is an unused character, but I believe GitHub interpreted it as a space. Indeed, when you use it this way, GitHub will automatically add a space, I guess to make sure other qualifiers can easily be added. Strangely, though, it will add a %20 to the end of the URL today, but again, you can simply omit that part. The %3A between the words no and assignee is the character code for Colon. See a full list here.
EDIT #4 (June 30, 2020): this is now possible via the UI: simply go to your issues list (https://github.com/<username>/<repo>/issues) then choose Assigned to nobody from the Assignee dropdown:
Go to the issues list and show issues assigned to yourself. Look in the URL bar and change where it has your username to none just after 'assigned/' and press enter. The UI will look the same but the list will have only unassigned issues.
e.g.:
https://github.com/<username>/<repo>/issues/assigned/none
One workaround would be to compare:
the list of issues
with the list of issue assigned to anyone
(the difference being the list of issues not yet assigned)
See GitHub V3 Api "list-issues-for-a-repository" section:
assignee
String User login
none: for Issues with no assigned User.
*: for Issues with any assigned User.
2021 Update.
In the search bar you must type no:assignee and this will show all Github issues without an individual assigned to it.

List all the files checked-in in a single cvs commit

Generally,our fixes/patches for any bugs involves changes in multiple files and we will commit all these files in a single shot.
In SVN, for each commit (may involve multiple files),it will increment revision number of whole repository by one. So, we can easily link all the multiple files that went in a single commit.
Now the difficulty with the same case in CVS is that it will increment the revision numbers of all the files individually. Let's say if a commit involves the following files:
file1.c //revision assigned as part of this commit..1.5.10.2
file2.c //revision assigned as part of this commit..1.41.10.1
and the comment given for this commit is "First Bug Fix".
Now, the only way to get all files checked-in as part of this commit is by searching through all the cvs logs for comment "First Bug Fix" and hopefully it will return only the two file revisions mentioned above.
Please share your views on if there is any better way in CVS to keep track of all files checked-in in a single commit instead of relaying on comment given as part of commit.
I think CVSps might do what you are looking for.
"CVSps is a program for generating 'patchset' information from a CVS repository. A patchset in this case is defined as a set of changes made to a collection of files, and all committed at the same time (using a single 'cvs commit' command). This information is valuable to seeing the big picture of the evolution of a cvs project. While cvs tracks revision information, it is often difficult to see what changes were committed 'atomically' to the repository."
This cvsps relies on cvs client. Make sure you have proper version of cvs which supports rlog command (1.1.1)
CVS does not have inherent support for "transactions".
You need some additional glue to do this. Fortunately, this has all been done for you and is available in a very nice extension called "cvszilla".
The home page is here:
http://www.nyetwork.org/wiki/CVSZilla
This also ties in to CVSweb, which is a great way to browse through your CVS modules via a web-based GUI.
Perhaps the ANT CvsChangeLog Task is another choice. See http://ant.apache.org/manual/Tasks/changelog.html . It provides date and time for a checkin message. You can produce nice reports with XSLT - try the example at the bottom of the ANT manual page.
I know it's late for an answer, but perhaps other users come across this like I did (searching) and appreciate the ANT integration.
OK, I just installed cvsps and ran it from the top level. Here's a sample of the output... this is one of the few hundred patch sets on my module. Note that indeed this does work across different directory trees.
---------------------
PatchSet 221
Date: 2009/04/22 22:09:37
Author: jlove-ext
Branch: HEAD
Tag: LCA_v1_0_0_0_v6
Log:
Bug: 45562
Check the length of strings in messages. Namely:
* Logical server IDs cannot be more than 18 characters (forcing a
TCSE protocol requirement).
* Overall 'sid' (filter) search string length cannot be more than
500 (this is actually more than the technical maximum messages are
allowed, but is close).
Alarm messages and are now not going to crash either as the alarm text
is shortened if necessary by the LCA.
Members:
catalogue/extractCmnAlarms.pl:1.2->1.3
programs/ldapControlAgent/LcaCommon.h:1.18->1.19
programs/ldapControlAgent/LcaUtils.cc:1.20->1.21
programs/ldapControlAgent/LcaUtils.h:1.6->1.7
programs/ldapControlAgent/LdapSession.cc:1.61->1.62
tests/cts-45562.txt:INITIAL->1.1
So, this may indeed do what you want. Nice one, Joakim. However, as mentioned, CVSzilla does much more than this:
Web-browsable CVS repositories (via CVSweb).
Web-browsable transactions.
Supports transactions across modules.
Generates CVS commands (using 'cvs -j') to merge patchsets onto other branches.
Integration with bugzilla (transactions are automatically registered against bugs).
If all you want is just the patchset info, go with cvsps. If you're looking to use CVS on large projects over a long period of time and are thinking about using bugzilla for your bug-tracking, then I would suggest looking into CVSzilla.
This also could be useful:
http://code.google.com/a/eclipselabs.org/p/changelog/