Hey, Jakob, it's been a moment. Thanks for your reply, I do appreciate your attention to this matter.
Perhaps I did not make myself clear: I am not proposing that this be merged into 9front as‑is. The intent of the pull request is to solicit comments and discussion, hence the "RFC" tag. The goal is to surface the approach, validate whether the compatibility adjustments make sense from the project’s perspective, and understand whether there is interest in maintaining cross‑edition operability in this form. It's fine to keep it as a "forever patch", rebasing periodically; though, such maintenance would be greatly simplified if the number of differences were kept minimal - hence the request for comments and considerations, a healthy debate that is, for partial uptake, perhaps, or other ideas. As before, feedback is very welcome. Kind regards, Yaroslav On Fri, May 8, 2026 at 9:50 PM Jacob Moody <[email protected]> wrote: > > On 5/8/26 13:38, Yaroslav K wrote: > > Hi all, > > > > I’ve completed a full backport of git9 to the 4th Edition / 9legacy > > environment. Earlier attempts existed, and I reviewed the 9legacy > > patches carefully, but even with all undocumented dependencies > > applied, the result still wasn’t in a state where the same codebase > > could run unmodified across systems. > > > > Instead of stacking more patches, I focused on the concrete > > incompatibilities that the port actually encountered: differences > > in rc syntax, flag parsing, libc interfaces, date/time formatting, > > awk behaviour, and the availability of certain helper utilities. > > None of these were major individually, but together they prevented > > a clean build and consistent behaviour on 4e. > > > > > > The goal was to make git9 edition-agnostic without forking much of > > the code. The result now builds and runs cleanly on both 9front > > and 4e/9legacy. > > > > In practical terms, this meant replacing newer rc constructs with > > legacy-compatible forms, avoiding the 9front-specific aux/getflags > > syntax, steering clear of newer libc calls like Bfdopen, using date > > formatting primitives available on both systems, working around awk > > differences, and importing a small set of auxiliary utilities so > > that behaviour matches across both environments. The PR contains > > the full details, but the overarching theme is reducing shallow > > incompatibilities rather than introducing edition‑specific branches. > > > > To install the port, use the contrib mechanism: > > > > contrib/install yk/git > > > > The RFC PR is here for anyone who wants to review or discuss the > > approach: > > > > https://github.com/9front/9front/pull/2 > > > > Apologies, I turned off PRs for the 9front repo since we do discussion through > our mailing list without realizing it would delete and make current PRs > vanish. > > I will say I find this a bit inconsiderate to the 9front project to purpose > that > we use this code. These changes between 9legacy and 9front were made for a > reason, > and we've made use of them (as you can see) in git9 to make our lives easier. > You are asking us to revert back to old interfaces (that we had a problem > with) > because now you specifically want this sub-portion of our tree? What happens > tomorrow > when someone else wants another program from us? Are all of 9front's "useful" > programs going > to need to be able to cleanly compile on 9legacy? > > - moody > -- - Yaroslav ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Td167d7e8cebadcc4-M01bdd0a7d5c3a2c110f4754b Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
