I've read the README (and I've also used git-subtree in the past), but it's still a bit unclear to me how this is intended to be used. What's the typical flow?<p>- When should I run `subtrac update`? Only once? After every change in submodules?<p>- 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?<p>- Does this allow me to make a change to the submodule and not push upstream, but instead "commit" it to the parent repo only?<p>- What is the master.trac branch? Should users checkout this branch, or is it just there for referencing data?
What's the use case for this? The way I see it is that `git submodule` and `git subtree` (and it's much better variant git subrepo) have two different optimal use cases with a huge amount of grey area in between.<p>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.<p>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?<p><a href="https://github.com/ingydotnet/git-subrepo" rel="nofollow">https://github.com/ingydotnet/git-subrepo</a>
Basically, git-subtree without history mangling, by turning each commit into the child of itself plus all the submodule link commits. No more disappeared upstreams or uninitialized submodules. Seems nice.<p>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?).
We have been using this since it was announced for our main repository. (The author of git-subtrac is my cofounder.) It is a definite improvement on storing submodules in separate repositories, where one of us would forget to push a commit and the other of us would have to wait for them to be online to get it.<p>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.)
And after I just spent several hours of headaches rebasing and wrangling git subtree and attempting to git rebase -i branch -s subtree --rebase-merges --allow-unrelated-histories (which doesn't work)...<p>Request: Is it possible to import only one subdirectory of another Git repository as a subtree (excluding unit tests and build scripts and such)?