Hi Evan,
On 15 September 2016 at 01:08, Evan Gates <evan.gates_AT_gmail.com> wrote:
> On Wed, Sep 14, 2016 at 1:33 PM, Evan Gates <evan.gates_AT_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
Received on Thu Sep 15 2016 - 09:09:24 CEST