I have a repository on GitHub.com. I need to add a large file to it (>1GB). git-lfs seems to be the solution but GitHub probably offers only upto 2GB for free. Can I use any other location as a separate large file server while the actual codes stay in GitHub?
I tried configuring lfs Endpoint to the Azure devops repo and the git origin to GitHub.com. It does not seem to be working that way.
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.
To set expectations, I'm new to build tooling. We're currently using a hosted agent but we're open to other options.
We've got a local application that kicks off a build using the VSTS API. The hosted build tasks involve the Get sources step from a GitHub repo to the local file system in VSO. The next step we need to copy over a large number of files (upwards of about 10000 files), building the solution, and running the tests.
The problem is that the cloned GitHub repo is in the file system in Visual Studio Online, and my 10000 input files are on a local machine. That seems like a bit much, especially since we plan on doing CI and may have many builds being kicked off per day.
What is the best way to move the input files into the cloned repo so that we can build it? Should we be using a hosted agent for this? Or is it best to do this on our local system? I've looked in the VSO docs but haven't found an answer there. I'm not sure if I asking the right questions here.
There are some ways to handle the situation, you can follow the way which is closest to your situations.
Option 1. Add the large files to the github repo
If the local files are only related to the code of the github repo, you should add the files into the same repo so that all the required files will be cloned in Get Sources step, then you can build directly without copy files step.
Option 2. Manage the large files in another git repo, and then add the git repo as submodule for the github repo
If the local large files are also used for other code, you can manage the large files in a separate repo, and treat it as submodule for github repo by git submodule add <URL for the separate repo>. And in your VSTS build definition, select Checkout submodules in Get sources step. Then the large files can be used directly when you build the github code.
Option 3. Use private agent on your local machine
If you don’t want add the large files in the github repo or a separate git repo for some reasons, you can use a private agent instead. But the build run time may not improve obviously, because the changed run time is only the different between copying local files to server and copying local files to the same local machine.
I'm trying to download a file from github repository and I would like to use ssh (using scp) instead of downloading it via HTTPS. Is that even possible? Could you give an example? Thanks.
No it's not possible. Git repositories don't consist of the actual files, but a collection of the incremental changes.
Therefore you have to clone a repository to get the file.
Github only offers the HTTPS download as "services".
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 develop front-end and back-end of many websites hosted on godaddy. I was looking for a way to synchronize the godaddy file manager with my local repository so as to prevent me from uploading the edited files each time. I push my code to github directly, but is there a way to push the code directly to godaddy account without using its file manager?
Also sometimes, with other systems, I edit the code directly on the server if I get some problems with the code, which becomes then difficult to get it on my local system.
It would be of great help to directly push it without using the file manager each time.
It would be best to:
install Git on Godaddy (as in this blog post)
setup a bare repo on the upstream side (ie, the GoDady side, the one where you would push your code)
add a post-receive hook on that upstream repo in order for a non-bare repo to update itself: see links in the "Is --bare option equal to core.bare config in Git?" answer.