I am working on a localization framework that managaes the text-assets for several applications (wpf,android,ios) in a library. We use git as the version control system for all the applications. Now I want to export those assets directly into the the git-repository.
The problem is: I dont want to clone/pull the whole repository every time i export the assets into the git repositories. In fact I dont want to know about any files exept those assets. I already figured out that checking out subdirs is not possible with git, but is there a way to “inject” or “force” those changes into the repository without having to pull all the other changes and files? (Note: the assets are only changed here and are not edited by the developers directly)
It should basically ignore everything that happens outside the assets folder.
Another imoportant thing is that it shouldn’t change the workflow for our developers, so submodules is not really an option since they would have to pull the submodule all the time.
Is there a good way to do this with git except ? Thanks in advance!
In git, a commit object references a tree object. That tree object then references blob objects. Each blob is (generally) a file in your working copy.
The commit identifier is a hash of the commit object, which contains the hash of the tree object, which itself contains the hash of all the blobs.
So, in order to make a commit, you must know the state of all blobs in the commit. The commit is, effectively, a snapshot of the whole working copy (technically, the index). This means you can’t just “ignore changes outside dir X”, because if you did that, your commit would produce a working copy either without those files (if you didn’t include them in the tree object) or with outdated copies (if you check out once and then assume they’re unchanged, putting the outdated hashes into the tree object).
This is why you can’t just check out a subtree in git and ignore changes outside of it. This is also why what you’re asking for (making a commit without ever looking at the state of other files) is impossible.
However, I think if you were to try the “git way” of doing things – cloning once, then committing many times from that one clone – you would rapidly discover it is a very low-overhead way of doing things.
Failing that, you could make your “assets” be a separate repository (possibly a git submodule, they don’t require a significant “change to the developers’ workflow”, really). Then you only have to clone the “assets” repository to make commits there.
You could also just send patches to the already-up-to-date server and have it do the commits locally. This wouldn’t involve ever cloning the repo, since of course the server must have the latest changes to other files (it’s the source you’d be pulling from!).