There is a way to get all the issues from a git repository? I need to populate a mysql database with the issues of a specific project with the issues status, reporter, priority, etc... Thanks!
Git and GitHub are two different things. The former is a version control system which does not know anything about “issues” or “tickets”, while the latter is a project platform with source hosting and issue management. So the GitHub issues are very specific to GitHub. No Git command will be able to give you GitHub issues.
There is hub (repository), a wrapper around Git, which adds a few GitHub specific functionalities, like interacting with pull requests from the command line. For all browsing-related tasks it refers to the web browser though. And that’s also GitHub’s primary interface.
There does exist an API for issues though, so you could utilize that. There is ghi which utilizes the API and does offer you access to GitHub issues from the command line.
Try ghi, here's what it does:
By default, ghi looks for GitHub issues by resolving the current
working directory's repository: first it looks for an upstream remote,
then it looks at origin.
Gives you a nice list of issues, a detail view, close/edit/assign features etc. I'm never leaving the terminal again.
Github provides a web api for their ticket system. It is documented here and you can write a small program to fetch them and look through them.
Related
We have some repos that we no longer need to keep on GitHub. If we use GitHub's archiving feature, the repos actually stay online. What we'd like instead is a way to download an archive of all the content (including issue reports) for a given repository, put that repository archive in a long-term preservation system, and delete the repo from GitHub. This is more than simply backing up a repository in the sense of other similar questions on Stack Overflow, and is more like what BackHub can do. Is there a tool or set of procedures (beyond git clone) that will allow me to do this?
python-github-backup can back up a single repository in an organizational account, as well as all repositories in an account. I have tried it on individual repositories, and it worked as hoped: using its --all option, it captures issues, labels, milestones, pull requests, and wiki pages, as well as the repo itself.
Googling "github-backup" leads to other similar tools, but most of the others seem to have fewer features than python-github-backup or haven't been updated for many years. However, I must admit I haven't explored the other options very carefully.
Tip: the essential ingredient in using Google to find a suitable tool seems to be to search for the words "github" and "backup" specifically, and not include "archive" as I was doing in my original search, or even use more elaborate search strings such as "how make backup github repository".
If is preferable to use git clone --mirror, to get the full repo history and then
git bundle --all to get only one file (easier to store than a collection of files)
a long term storage system (example AWS S3)
Notes:
you might want to clone the associated GitHub wiki as well, if you have one.
that won't preserve your issues/Pull Requests
Use a folder on your local machine, google drive, or dropbox. No need to use github on non-active projects.
My company has a Git repository hosted on our servers. We use TortoiseGit. I would like to integrate it with GitHub Issues.
Is this possible? Note that we do not host our repository on GitHub.
I have tried using the bugtraq settings on TortoiseGit but it doesn't interact with the repository I've set up on GitHub.
I would like to integrate it with GitHub Issues. Is this possible?
Integrate in this context is a very open concept. Which integrations are you looking for? If you're not hosting the code on the repository itself, any kind of integration will be hard, but it really depends on your specific goal with GitHub Issues and which kind of triggers and links you want from your code to your issues.
From experience if I assume that by integration you mean linking Git commits in your local repository to GitHub Issues the clear answer is no.
So if you really want to use GitHub Issues without pushing the Git code upstream, have you considered creating an empty project to just use GitHub Issues and GitHub Projects. You won't be able to reference issues from the commit message, i.e., Fixed issue found in #4 but you can use it as a standalone project management tool.
Trello offers a free tier for project management that you might also want to check out.
first: We use a github repository in the team for some projects.
I'm using scripts defined in the pre-commit hook directory, locally (works perfect for my commits).
What I need is for every user (collaborator) to use the hooks without using symlinks or asking them to put them on their home folders.
Is there a way to set them up so the users can't commit if the scripts don't exit 0?.
Thanks.
As Henrik alluded to, in the Enterprise version, there is such a thing as the pre-receive hook. It runs server side and so you would not need to install it on each collaborator's local machine. But you are using github.com actual, and they don't allow pre receive hooks , nor do I expect they plan to; allowing indivduals to run scripts on their server isn't likely in their business plan. So that likely won't help you unless you are in a position to go to the enterprise product
There are some remedies you do have, however, but it won't be equivalent. You can , for example, set a protected branch . You could thereby make it only you can check into that branch, and you of course would be using the local hook, every one else would be using a pull request.
Additionally, you could look into LGTM (Looks Good To Me) or similar automated pull request approval system. I don't believe the official server is up but the source code is there and it could be run by someone else. LGTM allows you to set a number of different conditions that would be closer to an equivalent to your pre-op hook.
Setting up such a system might well be more effort than it is worth to you, understandable; but it is do-able.
The main problem with using pre-commit hooks that come with git is that they are local to your repos and don't get pushed to github.com. I believe under the hood, those hooks aren't even transferred up to the repo on github, and that the pre-commit hook directory itself is not available like it is on the local copy of a git repo.
(I would say more on that architecture of the pre-commit hook dir except A. I am not sure if it is covered by NDA and B. I only saw the way it was on the Enterprise product, not github actual, and C. I don't know if the structure is still exactly the same)
We are using Eclipse with a SVN client plug-in. This client needs a server running; what about Git? We need to work in a LAN environment without internet access. I have read some basic tutorials about using Git with Eclipse. If I got a Java project in my Git repository, how can I share it with my teammate?
Even though you can share your local repositories, I would suggest setting up a server. There many free alternatives like:
gitlab (http://gitlab.org)
gitorious (http://gitorious.org)
gitolite (https://github.com/sitaramc/gitolite)
gitblit (http://gitblit.com/)
But IMO the best one is Atlassian Stash which for small team will cost you only $10.
if you need to share it, you need some way to access it from each other. Bitbucket is great for small teams who need private code.
If you are always using it from inside a LAN one of you should set up a shared section which you can all push your git changes too (a shared folder or shared drive is good enough) but i would recommend using github / bitbucket if possible
from a command line (can probably use it within eclipse too)
git clone file:////192.168.1.100/code
and then you can psuh and pull from 192.168.1.100/code assuming you have write permissions there
if you're coming from subversion to git, you will be faced with the concept of local repository vs shared repository. You will be able to have a local repository on your computer where you can do as many commits as you want and then only push relevant changes to the shared repository (the one that your teammates will be able to see).
Here's an useful link on the possibilities to share a repository: http://www.jedi.be/blog/2009/05/06/8-ways-to-share-your-git-repository/ (ignore the last one, GITHUB, which will require internet access).
In your particular situation I would recommend sharing via SSH or via GIT daemon.
I also really recommend you to take a look on Eric Sink's book here. He's even offering hardcopies for free!
as suggested you can run your own instance of gitolite or gitlab, but for a rudimentary solution i suggest you just check the following answer:
https://serverfault.com/a/113688/181010
basically you can use any folder as a shared repository as long as all users can access the files either locally or via ssh. that link discribes how to tell git to create its file with rights that are appropriate for usage by all users of one unix group (instead of only the single user owning the files).
I've recently been looking at using Git to eventually replace the CVS repository we have at work. However after watching Linus Torvalds' video on YouTube about Git it seems that every tutorial I find suggests using Git in the same way CVS is used except that you have a local repository which I agree is very useful for speed and distribution.
However the tutorials suggest that what you do is each clone the repository you want to develop on from a remote location and that when changes are made you commit locally building up a history to help with merge control. When you are ready to commit your changes you then push them to the remote location, but first you fetch changes to check for merge conflicts (just like CVS).
However in Linus' video he describe the functionality of Git as a group of developers working on some code pushing and fetching from each other as needed, not using a remote location i.e. a centralized location. He also describes people pushing their changes out to verifiers who fetch and push code also. So you can see it's possible to create scalable structure within a company also.
My question is can anybody point me in the direction of some tutorials that actually explain how to do this distributed development of code using Git so that developers push and fetch code from each other with out committing to the remote repository and if possible it would be very nice to have this tutorials Eclipsed based.
Thanks in advance,
Alexei Blue.
I don't know any specific tutorial about this. In general, for connecting to a repository, you have to be running a git server that listens (and authenticates) to git requests.
To have a specific repository for each developer is possible - but each repository needs that server component. It is possible to store multiple repositories on the same computer, that allows reducing the number of servers required.
However, for other reasons it is beneficial to have some kind of central structure (e.g. a repository for stuff to be released; or a repository for stuff not verified yet). This structure is not required to be a single central repository, but multiple ones with well-defined workflows regarding the data move between repositories (e.g. if code from the verification repository is validated, it should be pushed to the release repository).
In other words, you should be ready to create Git servers (e.g. see http://tumblr.intranation.com/post/766290565/how-set-up-your-own-private-git-server-linux for details; but there are other tutorials for this as well), and define workflows for your own company to use it.
Additionally, I recommend looking at AlBlue's blog series called Git Tip of the Week.
Finally, to ease the introduction I suggest to first introduce Git as a direct replacement for CVS, and then present the other changes one by one.
Take a look at alblue's blog entry on Gerrit
This shows a workflow different from the classic centralized server such as CVS or SVN. Superficially it looks similar as you pull the source from a central Git server, but you push your commits to the Gerrit server that can compile and test the code to make sure it works before eventually pushing the changes to the central Git server.
Now instead of pushing the changes to Gerrit, you could have pushed the code to your pair programming buddy and he could have manually reviewed and tested the code.
Or maybe you're going on holiday and a colleague will finish the task you've started. No problem, just push your changes to their Git repo.
Git doesn't treat any of these other Git instances any different from each other. From Git's perspective, none of them are special.