On 1/23/25 16:49, Steffen Nurpmeso wrote: > Hello. > > Jacob Moody wrote in > <f6c74829-1192-4fc8-a474-318676655...@posixcafe.org>: > |On 1/22/25 23:37, Steffen Nurpmeso wrote: > |> Tomoaki AOKI wrote in > |> <20250123074932.170b7959bca443a934599...@dec.sakura.ne.jp>: > |>|On Thu, 23 Jan 2025 07:40:50 +0900 > |>|Tomoaki AOKI <junch...@dec.sakura.ne.jp> wrote: > |>|> On Wed, 22 Jan 2025 14:31:56 -0700 > |>|> Warner Losh <i...@bsdimp.com> wrote: > |>|>> On Wed, Jan 22, 2025, 2:11 PM Tomek CEDRO <to...@cedro.info> wrote: > |>|>>> On Wed, Jan 22, 2025 at 5:49 PM Gleb Smirnoff <gleb...@freebsd.org> \ > |>|>>>> On Wed, Jan 22, 2025 at 09:30:09AM -0700, Warner Losh wrote: > |>|>>>> W> I think what you want is > |>|>>>> W> > |>|>>>> W> % git clone https://github.com/freebsd/freebsd-src --depth=1 -b > |>|>>> releng/14.2 > |>|>>>> W> --single-branch fred --bare > ... > |>|>>>> W> % git checkout releng/14.2 > |> ... > |>|>>>> I really like this plan. So before checkout .git is 337M and after > |>|>>> checkout > |>|>>>> it is 975M, which is made by actual sources + .git. > |> ... > |>|>>> One question, would that imply git in base? :-) > |>|>> > |>|>> Imply? No. > ... > |> The Plan9/9front people have -- btw -- created a Plan9-style > |> interface to git, which is funny it seems (filesystem plus minimal > > That is, an implementation of their own that is capable to > interact with normal git packs and objects (i think). > > |> programs using that, most are rc shell scripts. I track their > |> repo via "normal" git (git://git.9front.org/plan9front/plan9front) > |> without problems since June 2021 says the file system. > ... > |> What i mean seems to be that these guys already have the knowledge > |> how to access the object database without any fancy and featureful > |> and fat environment, so if FreeBSD would do that then possibly > |> a simple from scratch checkout -- and nothing else -- would be > |> possible with only shell tools and a small binary that fetches the > |> blobs? Maybe even only possible with a very specific tree, you > |> know? As in a readily prepared recipe (could be compressed and > |> reside in the .git directory) that can be walked by the shell > |> script(s) and accessed by the super minimal blob fetcher? > |Only getting bits of this conversation it's hard to infer exactly what > |the goal is. Is the issue wanting to use git in a way that would require > |it to be present within the base system, but encountering issues with doing > |so due to licenses? The git present in 9front is MIT licensed, and \ > |has already > |been used in part for OpenBSD's game of trees (got). I imagine taking \ > > I think they tend to keep the base system more "clean" as in the > past, making use of pkg and ports even for tools they effectively > need, ie, all developers necessarily need git, but it is not part > of the base system as cvs as been in the past, for example. > License, they try to go BSD etc, and replace GPL etc software as > BSD etc software can replace it. There is GPL still, for example > diff(1). > > |whatever > |pieces are required to bootstrap what you want from git9 would be sensible. > |Git9 lacks some things (shallow clones for one), but is largely an entirely > |usable interface to git, so I imagine it would have everything you \ > |need if not > |very close to what you need. That seems like a path forward, if people \ > |don't > |mind doing the port work. > > I myself was only thinking of really only a simplemost program > that works like "git show" aka "git cat-file". > Ie, they have mtree(8) or could otherwise create a snapshot of > the checked out tree at a specific git revision, noting access > rights etc (though this normally is not stored except for X bit in > git i think), symlinks etc etc for one. > And then walking this list of files and only fetching the file > content from the (single, aggressively gc'd) git object .pack / > .rev / .idx combo, cat(1)ing it into the fs, you know. > So "nothing but a simple fetch-the-blob-data" thing.
Sure, so you want the files out of the objects without the entirety of git(1). > > Like this no git(1) is needed at all to checkout a work tree from > a repository with no checkout at all / that has checked out an all > empty branch. > > |If you're looking for more technical details of how git9 works Ori \ > |did a write up > |for the IWP9 last year[0], which goes in to pretty good detail. > | > |[0] http://10e.iwp9.org/10iwp9proceedings.pdf > > Yes, i know; and thanks i have downloaded and read most of the > stuff. I was only hoping for a quick statement on how complicated > the envisioned program would really be, from a person who went > down that road on its own. Or even, best, a "hey i have code > which could be used for this with not much effort", you know.. > >From my perspective it seems like you just want git/fs and then to build whatever minimal tooling on top of that. All that git/fs does is take the objects and present the actual files and trees held within. The "hey I have code which can be used for this with not much effort" _is_ git/fs, it doesn't do much more then that. It's already fairly slim as-is: cpu% wc -l /sys/src/cmd/git/fs.c 922 /sys/src/cmd/git/fs.c I thought this was all laid out pretty straight forward in the paper, so that's why I thought you hadn't read it. Thanks, moody ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T16a2bbbe7794d5cd-Me86570ef4c1501898026cc95 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
