Git-subtrac: all your Git submodules in one place
apenwarr.ca
apenwarr.ca
- When should I run `subtrac update`? Only once? After every change in submodules?
- What happens if I go into a submodule folder and change a file? Should I commit inside that repository and push upstream? How is that propagated to the the parent repo?
- Does this allow me to make a change to the submodule and not push upstream, but instead "commit" it to the parent repo only?
- What is the master.trac branch? Should users checkout this branch, or is it just there for referencing data?
1. You should run it every time you make a change in a submodule.
2. You commit inside the subrepo, then run 'git subtrac update' in the parent repo. You don't need to push the subrepo anymore unless you want to (eg. because you're submitting upstream). You do need to push the new .trac branch in the parent repo somewhere - probably to the upstream parent repo.
3. Yes, exactly right.
4. It exists just to create references to all the objects in all the submodules. If you push it somewhere, then you can fetch all your submodules from there. The most common place to put it is in the parent repo, so that cloning that repo gives your users a clone of all the dependent submodules too.
Hope this helps!
Git subtree is your better option if your repo is one logical thing, and git submodule is your better option if you repo is a sparse collection of things.
AFAICT, git subtrac is aimed more at the git subtree / git subrepo use case since it stores the submodule commits in the parent repo? If so, what are the pros & cons versus git subrepo?
For example, one advantage of git submodules over git subrepo is that it allows much smaller repositories. Since subtrac copies the commits into the parent repo, it doesn't have that advantage.
That's one reason among several why I say that subtrac looks more like subrepo even though it's built on submodule tech.
I don't think there would be a size benefit regardless, since you would still be cloning the submodule from somewhere.
There are good reasons why you would want the contents of a submodule to remain a submodule. If you have a documentation wiki, or some sort of helper program, or a data repo, you would probably be better having it be a submodule. But submodules are awkward for a variety of reasons.
Note that this is from the original author of git-subtree. If this turns out to be a good idea, I wonder if it will make it into git/contrib, too (is a contrib written in golang even possible?).
Noticed any common thread there? All scripting languages.
$ cd ~/src/github.com/git/git
$ git ls-files '*.go'
contrib/persistent-https/client.go
contrib/persistent-https/main.go
contrib/persistent-https/proxy.go
contrib/persistent-https/socket.go
There is still more needed to make git submodules a pleasant user experience, but this was a big missing piece of the puzzle. (Submodules mean to you need to know a ton about how git works before you can do even the most basic things.)
One of my biggest annoyances was how you may have multiple submodules that are tightly related to your project, but have to be in external repos that may not logically map well.
One trick I started doing was to put the actual submodule repos physically inside my parent repos on my server, and then in my .gitmodules, using the relative directory like ./submodule1.git
So, that means:
parent/ --> server:parent.git
parent/submodule1/ --> server:parent.git/submodule1.git
The reason this is such a big deal, is that for many of the data projects I work on, the different repos, while closely related, should really have completely separate history. This is because I use tools like git-annex and git-lfs to access and push large datasets within git, and it would make no sense at all to mix that in with documentation and code. I sometimes use Datalad, which handles a lot of this, but had some of its own quirks and can be overkill some times.
I'm certain to give this a try.
Such as:
parent/
imaging_input/ (12G of 50G checked out w/ git-annex)
imaging_diffs_input/ (5G git-lfs)
imaging_output (git-annex)
logs_output/ (git-annex)
code/
wiki/
Request: Is it possible to import only one subdirectory of another Git repository as a subtree (excluding unit tests and build scripts and such)?
Edit: to be clear; even before 0.4.0 git subrepo handled strange situations better than git subtree did mostly because git subtree requires so much more manual work that's easy to get wrong.
What someone might want to try is extracting a subdirectory using git-subtree, and then importing it elsewhere using git-subtrac.