I am currently working on a flashcard application where decks created by the user act as Git repositories. When a card is created in the app, a new file is committed to the repository, when a card is changed, the file is changed, and when a card is deleted--well, you get the point.
The file format that the application saves to is a gzipped Git repository, so at no point will I ever need to write the repository to disk. How can I best handle treating decks as a Git repository in this way?
Take a look at libgit2. It supports the in-memory git repository scenario and also has bindings to many languages:
https://libgit2.github.com
For example, by using rugged, the ruby binding for libgit2, you could do things like this:
a_backend = Rugged::InMemory::Backend.new(opt1: 'setting', opt2: 'setting')
repo = Rugged::Repository.init_at('repo_name', :bare, backend: a_backend)
Related
I'm hosting a bare repository on Windows Server 2008 with Windows Git and OpenSSH.
For legal reasons, I want some files to be inaccessible for a specific user but remain accessible to all other users. In other words, I want certain "restricted" files to be ignored (non-pullable) for a specific user.
Assume we have two users (Administrator and Guest) and a Git repository with 2 files : (a.txt and b.txt).
Assume "b.txt" is a restricted file that Guest should not have access to.
git clone guest#ipaddress:C:/path/to/repository.git or
git pull guest#ipaddress:C:/path/to/repository.git
should clone or pull "a.txt"
git clone administrator#ipaddress:C:/path/to/repository.git or
git pull administrator#ipaddress:C:/path/to/repository.git
should clone or pull both files.
Is there a way to achieve this result with .gitignore or .git/info/exclude?
Is there a way to achieve this result with .gitignore or .git/info/exclude?
No.
Git is all about commits, and pull (really, git fetch) and push operations transfer commits. Commits contain files—a commit consists partly of data (a snapshot) and partly of metadata (information about the snapshot)—and you either have a commit, in which case you have all the files, or you don't have a commit, in which case you don't have all the files.
Files that need restrictions for whatever reasons—legal, corporate, or otherwise—must either not be in Git at all, or stored in some sort of pre-secured fashion (e.g., encrypted). In general the "not in Git at all" approach tends to work best. Consider storing, in Git, the URL of a restricted Web site that stores the actual file.
It's not possible to restrict user access to only parts of a repository. gitignore files are designed to prevent people from accidentally checking in code they didn't intend, not to restrict access to code already in the repository.
Even solutions that limit access to refs can be bypassed by a clever attacker in a way that lets them exfiltrate data from the repository. You should assume anyone with read access to a repository can read all of the objects in that repository; if you need to restrict some users' access to certain data, it needs to either be encrypted or live in a different repository.
I am trying to setup spring cloud config server. I see that there are two options for storing properties. Either Git or Native file system. Looks like people are more leaned towards using GIT against Native.
Our project follows trunk based development meaning it does not cut the branch on every release to production.
If we use GIT to read properties, and if someone change the property after deployment, then there is likely that changed property will be read which may create problem in production.
Did anyone faced the issue? How did you solve them?
If your Spring Cloud Git Backend is set to a tag or commit id (and not a branch), any modification should not be read.
This repository implementation maps the {label} parameter of the HTTP resource to a git label (commit id, branch name or tag).
If the git branch or tag name contains a slash ("/"), then the label in the HTTP URL should be specified with the special string "(_)" instead (to avoid ambiguity with other URL paths).
Since a commit id or tag is immustable, that should avoid reading a new content.
I made an application in Heroku with a PostgreSQL addon and I want to transfer them to another account.
I didn't find any "transfer to another account" option for the PostgreSQL addon. Does it move automatically with the app? Should I create another database in the destination account and link it to the app after transferring it?
Will the repository location be affected? Do the collaborators have to re-clone the repository?
How long will the transfer process take? While it is transferring, can we still view the app / push code to it?
When you transfer a Heroku app its add-ons should come with it. Transfers take place very quickly once the receiver has accepted the transfer, and the transfer process shouldn't affect the running app.
The Heroku Git URL will change, but you shouldn't be using this as your main code repository:
Heroku provides the git service primarily for deployment, and the ability to clone from it is offered as a convenience. We strongly recommend you store your code in another git repository such as GitHub and treat that as canonical.
Nobody should be cloning from that URL. Either way, you'll have to update your Heroku remote's URL, e.g. using git remote --set-url.
I have an existing Git repository, with working copy, connected to a GitHub remote repository (my local repository is on Windows).
I would now like to allow another developer to clone my local repository and connect to it as its remote repository.
Is this possible?
I have installed GitStack for Windows, but I see only the possibility of creating a new repository - not setting up an existing local repository to be used as a remote repository for another repository.
If this is not possible, is there some way I can set up my Git infrastructure so that I can achieve the same end - i.e., so that when the other developer commits, I do not have to do anything and those commits appear in my existing Git repository?
Yes, a regular Git repository (non-bare, with a working copy) can be cloned.
For example, assume your existing repository exists at C:\my-repo\. You can clone it to C:\my-repo2\ like this:
cd /d c:\
git clone my-repo my-repo2
Cloning it from another machine is a bit different, since you need to open up a network path to your existing repository. On a Linux system I would recommend enabling SSH or using git instaweb. Of course, both of these can work on Windows, but setting them up isn't nearly as easy.
Looking through the documentation for GitStack, you probably want to follow these instructions for importing an existing repository. Point GitStack at your existing clone and you should be good to go.
A note on pushing
As Hashem Qolami points out, by default the non-bare repository will not accept a push to its active (checked-out) branch. You have a few options here.
Read about receive.denyCurrentBranch in git help config and decide whether you want to enable pushes to the checked out branch. I wouldn't recommend changing this setting, but it should be mentioned as an option.
Have downstream developers push to a different set of branches. For example, decide that downstream developers will push to branches called developer-name/branch-name. Then merge the branches in the upstream repository.
Instead of having downstream developers push into the upstream repository, enable incoming Git connections to downstream machines as well and fetch (or pull) downstream changes into the upstream repository.
We are a team of less than ten persons that need to quickly set up a git server that supports active directory based authentication.
The simplest solution seems to be to use a file share with a bare git repository and reaching it using a unc path, e.g.
git clone //server/share/repo.git
However, we are a bit worried about robustness. Are there no issues with concurrency when several people use the same git repository and there is no actual server component running?
Clients are running windows 7, server is Windows Server 2008R2. Using msysgit 1.8.1.2
(I am well aware that there are many other git server solutions, but, especially given the requirement of AD authentication, they are not as simple to set up)
It seems the only times the AR Auth will be in play is pushing/pulling.
When you clone the git repo, the entire history will be cloned as well, so every user will have a complete repo.
If the file share fails, any user can replace the code on a new share by pushing their code up.
Concurrency is not an issue - since git is distributed it handles concurrency differently from other VCSs: no file locks, etc.