Hi Evan, On 15 September 2016 at 01:08, Evan Gates <evan.ga...@gmail.com> wrote: > On Wed, Sep 14, 2016 at 1:33 PM, Evan Gates <evan.ga...@gmail.com> wrote: > documentation, I realize I misunderstood submodules, and subtrees are > a better fit. > > For example, using sbase: > > git remote add sbase git://git.suckless.org/sbase > git subtree add -P bin/sbase --squash sbase master > > Now the entire sbase codebase has been checked out in bin/sbase (note > the use of --squash so we don't get the entire commit history in the > log). We can make changes, in this case probably just adding a > stali.mk as no other changes need to be made to sbase. If there are > upstream changes we can pull them in:
[..] > It all comes down to: Is this a good use of the capabilities of git? > Or does this suck because it goes beyond most people's knowledge of > git? I think it's a good solution to the problem of pulling updates > into stali. It looks appealing at first glance, but when thinking further it also brings several risks with it. For instance, if you rely on some repo that is hosted elsewhere, it could become unavailable at some point or the upstream changes might break the stali build. If all repos would be under our control and might also include some stali branch, then things could work. But I'm kind of old school nowadays and would consider the whole git subtree (same applies for submodules) feature as bloat and unnecessary complexity. It should not be part of git itself (even if it is). My updating strategy so far involved manual copying and worked well so far. It also gave me the freedom to patch here and there some lines of code if necessary for a stali target build. I believe this can only work well for the real core stuff. You may have noticed that I already removed the linux kernel sources and keep them in separate repos. What I imagine goes into your direction, but with a different toolset. Google invented the repo script for Android development many years ago. I don't like the repo implementation and its reliance on a crappy XML format, but I do like the idea of having a meta-repo management tool. Hence my suggestion for stali's future source organisation is something like repo, but a suckless version of it. I have the following in mind: Let's call the tool metasrc, it consists of a metafile that contains the format: # comment local/path/situation:git-url[#tag|ref|branch] ... You would run: ; metasrc sync http://git.sta.li/meta-stali/{x86_64-0.1|pi-0.2|...}.metafile to initially checkout stali for the given target. Later on you could keep pulling by running: ; metasrc pull anywhere. In a metasrc controlled tree git targets the current individual repo (in your path), metasrc would always target the whole tree. Everything except sync is interpreted as argument for one or many git calls (depending on your tree). It is similar to repo forall. This has also the advantage, that in theory one could also deal with other source control systems, if some repo is not available as git but instead as hg or even just a tarball. I can imagine to switch to something like this. -Anselm
