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> % cd fred > |>>>> W> % mkdir .git > |>>>> W> % mv * .git > |>>>> W> % git config --local core.bare false > |>>>> W> > |>>>> W> This will clone 1 deep into the directory 'fred' and won't \ > |>>>> checkout a > |>>> copy. > |>>>> W> If > |>>>> W> we make this a package, it's 325MB, as you say. That can then be > |>>> extracted > |>>>> W> and then you can recover the tree with: > |>>>> W> > |>>>> 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. > ... > |> Can it be achieved by net/gitup, which is BSD2CLAUSE licensed? > |> If yes, is there any plan to pull it into base? > |> > |> I've never tried it, as I'm not enouch sure it works sanely with local > |> deep-cloned repo, even on stepping back to normal git. > |Unfortunately, found that gitup states NOT to work with the existense > |of.git directory. Not sure how the future plan (if FreeBSD starts > |including .git for src and ports packages). > | > | https://github.com/johnmehr/gitup?tab=readme-ov-file > > I have not looked for years, but basically it was a tree object, > and then getting the blobs of all the entries of that, at > a specific revision. > > The Plan9/9front people have -- btw -- created a Plan9-style > interface to git, which is funny it seems (filesystem plus minimal > 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 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. 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 Thanks, moody ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T16a2bbbe7794d5cd-Me5f66262805800dec23830ed Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
