What I'm trying to do is know what particular subdirectories have changed after pulling from a git repository. I was thinking I could compute the hash of all the subdirectories in the root directory, then pull git, then compute the hashes again. If the hashes don't match, then I know which directories have changed.
Is there a common way to compute the hash of a directory tree? I feel like this is pretty much what git does internally to track its files.
I would prefer a C, or better yet, objective-c api to do this, but i'd settle for a unix command to do it.
thanks for any tips.
Computing a hash of a directory hierarchy is expensive, especially in a large git repository.
You should look at the API provided by git. There may be a way to ask git to tell you what it is changing.
You should look at OS X's file system events API. This can send your app a notification when something in a directory hierarchy changes.
https://developer.apple.com/library/mac/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html
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
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.
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.
I've started using git-svn for an SVN-based project, so that I can make local commits.
However, the SVN repository contains a lot of directories that I don't need to work with. When I solely used SVN, I was able to partly check-out stuff with:
svn co <repos-url> --depth empty
and then update the needed directories:
svn up <repos-dir>/<subdir>
As far as I've understood, partly checking out a project isn't an option with Git, so I'm looking for alternative way of saving some space. Any suggestions?
Edit: what I am thinking myself is something in the lines of creating a branch thatonly contains the files I need. I'd then want to be able to push the changes to these files without pushing any removal of the files I don't need. But I am not too deply into the way Git works to figure out if this is possible?
Are the extra directories really that big? One advantage of Git is that you do most of your work from your local harddrive (you commit to your own branch, not to the server) so it's fast even when there are many files.
I want to create a bazaar repository and have the .bzr directory not alongside the versioned files.
I'm searching for an option like "--git-dir" in git, or a way to achieve the same thing. Evenctually I'd accept an hack too.
A solution using bzrlib is feasible
Example current structure
project/.bzr
project/foo_versioned_file
project/bar_versioned_file
Wannabe structure
project/foo_versioned_file
project/bar_versioned_file
/unrelated_path/.bzr
There is nothing like --git-dir in bzr, but if you only need avoid having the full history along your working tree, then it's worth to consider using lightweight checkouts. Lightweight checkouts allow you to use only small number of files in .bzr/ directory (but you have to have it anyway) and the real branch with its repository and its history can be kept outside the working tree. So:
bzr branch bzr+ssh://HOST/REPO/BRANCH /unrelated_path
bzr checkout --lightweight /unrelated_path project