This article mentioned to redirect objects and refs folder to database, can other files under git repo (.git folder) be redirected in similar way?
libgit2 allows you to replace the default accessors so you don't have to store data in the git-dir, but it does not provide a way to avoid having the git-dir.
The git-dir is where Git stores data about the state of the repository, which includes references, a configuration file and the objects. These are three things which you can ask libgit2 to use a different object instead of the one which does look at the directory as git creates them. This can make those repositories not be compatible with git itself, so it's not a decision to be taken lightly.
But the git-dir also contains an excludes file, the index, hooks, MERGE_HEAD and the other _HEAD files, the temporary files for the commit's message, the rebase's instruction sheet... None of these things are full-blown objects which libgit2 lets you plug in, some of them aren't read by libgit2 at all either.
Related
I have a repository and I need work done by some subcontractors, let's say.
Instead of splitting the repo up into dependencies, to hide proprietary code, I can easily put all of the non-sensitive code in a folder, and somehow just give the subcontractors access to this one folder. Is this a good use case for git submodules? If so, what might the workflow look like exactly?
Nohow just give the subcontractors access to this one folder. Git doesn't operate on the level of subtree
Submodules is bad choice, consider subtree
Both submodules|subtree mount as subfolder external independent repo, thus you have to split original repo anyway
We have a terraform module developed and kept it inside a repo and people access it by putting below in their main.tf
module "standard_ingress" {
source = "git::https://xxx.xx.xx/scm/xxxx/xxxx-terraform-eks-ingress-module.git?ref=master"
When they do terraform init whole repo is being cloned to folder (~/.terraform/modules/standard_ingress)
We have some non module (non terraform) related folders as well in the same repo and same branch.
Is there a way, we can make terraform init exclude those folders being cloned.
Thanks.
The Git transfer protocols all work by transferring batches of commits associated with a particular remote ref (branch or tag), so there is no way for a Git client to fetch only a subset of the directories or files in the selected commit.
Terraform can only use the Git protocol as it's already defined, and so it cannot provide any capabilities that the underlying protocol lacks.
If your concern is the amount of time taken to clone the entire repository, you may be able to optimize by excluding anything except the most recent commit rather than by ignoring files within that commit. You can do that by setting the depth argument to 1:
source = "git::https://xxx.xx.xx/scm/xxxx/xxxx-terraform-eks-ingress-module.git?ref=master&depth=1"
If even that isn't sufficient then I think your only further option would be to add a separate build and release step for your modules where you capture the subset of files that are relevant to the Terraform modules into a .zip or .tar.gz archive, publish that archive somewhere that Terraform can fetch it over HTTP, and then use fetching archives over HTTP as the source type. In this case Terraform will download only the contents of the archive, allowing you to curate exactly what's included. (It would also be equivalent to put the archive into one of the supported cloud storage services, such as Amazon S3.)
I want to remove untracked files from the working tree. Like here
https://www.kernel.org/pub/software/scm/git/docs/git-clean.html
libgit2 doesn't implement this itself. It's a porcelain command, which deals with interaction with the user. It also deals primarily with files which are of no interest to the Git repository.
You can run status to see which files are untracked and then remove whichever ones the version of git-clean would have removed through the usual means available in your programming language.
I try to write a file store based on libgit2.
Software snapshots should be saved as branches mysoftware and specific versions committed and tagged. Then later I want to checkout the tags to different directories.
When looking at git_checkout_tree, it seems like there is only one working tree for a repository and thus it does not even seem possible to checkout multiple working trees concurrently.
Is this correct!?
EDIT:
Additionally, I would like for this thing to work on Windows without the need for cygwin!
The git_checkout_opts structure in libgit2 contains a target_directory option that will allow git_checkout_tree() to write to a different directory instead of using the default working tree for the repository. This would allow you to custom build a solution with libgit2 that maintained multiple checked out copies.
Without using that option, a libgit2 git_repository object expects there will be just one working directory and looks to the core.worktree config option if it isn't the "natural" working directory for the repository.
The git-new-workdir tricks with symlinks in the .git directory don't work great with libgit2 right now, I'm afraid, and particularly doesn't work well on Windows. I'd love to see this addressed, but it isn't too high on my priority list.
Git doesn't support this natively, but you can use git-new-workdir to do it.
so yeah just wondering if darcs has anything equivalent to git's submodules.
i.e. lets say I have a repo (myapp) and I have a folder in it called mylibrary. mylibrary doesn't really have anything to do with myapp's development, it just has to be included. mylibrary's development happens in it's own repo, but when someone pulls myapp, it'll also pull an up-to-date version of mylibrary. any ideas?
My first thought: Since darcs is simpler than git (i.e., no branches and remotes--instead you just use directories and URLs, and it's your task to manage them), a darcs submodule would not give much more than what you can achieve with standard things like subdirectories or files inside you darcs repo.
If you needed a submodule in order to fix a certain state of the source of the used library, you could perhaps simply put a copy of the library's repo as a subdir and add it to your project's darcs. Compared to git, this would have the disadvantage of bloating the data transfer when someone gets your repo.
If you needed a submodule to tell those who get your repo where to get the updated source of the library (without bloating the size of your repo), you could simply put an URL and an instruction into a README file, or a script, or whatever. Compared to git, the disadvantage is that the state of the library's source as it was when you used it wouldn't be recorded in your commit, so people might get another version of the library, and the compilation wouldn't succeed, and it wouldn't be clear why.
So, the really interesting goal of a submodule could be not just to tell people where to get the library source from (as you write in the question), but to record the state of the subproject that you have actually used for compiling your project, and not to bloat your repo for those who don't want to get the source of the subproject.
Probably, this goal could also be achieved by storing more complex metadata about the state of the subproject, and a more complex hook to get exactly that state (or--by choice--another state) of the subproject. AFAIK from the docs, there is no built-in mechanism for such submodules.
Update (found on the darcs site):
http://darcs.net/Ideas/Subrepositories;
http://darcs.net/Ideas/NestedRepositories.
So, darcs will notice another darcs repo inside your working and it won't touch it. So the first way I've suggested above is shut (if you leave the darcs metadata there).
The second way is like something suggested in one of the section of the latter link. (They suggest an "uglu" script for something like this.)
Another (3rd) idea
Import the patches from the repo you intend to have as a submodule, but first move all files into a subdir. If it were possible just to apply such a moving special patch once and if it was effective for all the patches you import from the repo intended as submodule, but not to the patches you import from a "branch" of the main repo...
...well, it could be a special variant of the pull command (say, import) and of the push command (say, export) that would additionaly translate the paths accordingly.
I don't know of any submodule concept for darcs, which means the usual way to refer to another (shared) repo from a darcs repo would be through symlinks.
Since symlinks aren't supported with darcs, that means you needs to put in place a "posthook sh update-symlinks.sh" hook script to restore those links.
But you could also use add to this hook a check to see first what version of the lined repo is currently loaded, and update that version if needed (provided you have store in one way or another the exact version you need for that shared repo).
That last suggestion is actually close to the implementation of Git submodules or Mercurial subrepos.