How we handle Upstream Repos in the future?! | GT New Horizons | Page 1

stuck spoke Feb 14, 2025, 10:38 AM

#

I will copy all repos that are still in development for GTNH and leave them as they are.
Then I create a additional GTNH branch in which I generate a runnable version for testing or until we get a new tag from the respective developers.
This will then be in our repo (Github Tag/version) and on the Nexus (For infrastructure like Daxxl and others) to be used in new nightly builds.
(until we get an adequate version from the original repo or site)

Anyone who would like to support me for this or a similar new workflow is welcome to do so constructively.

#

@cobalt sparrow feel free to add this branch as pr to upstream https://github.com/GTNewHorizons/Salis-Arcana/tree/fixes

cobalt sparrow Feb 14, 2025, 10:46 AM

#

already recreated it on a personal fork

#

thanks though

#

replace master with the default branch of upstream*

cobalt sparrow Feb 14, 2025, 11:34 AM

#

@stuck spoke can you also make a note at the top of the description on the side for each upstream repo that says [UPSTREAM ACTIVE - PRS GO THERE]

paper juniper Feb 14, 2025, 4:25 PM

#

the trick with these is just keeping our default branch perfectly in line with upstream, then maintaining is easy from there. its conceptually the same as how we do our repos;

dev branch for our nightly tags
default branch for real releases, its just that we dont do these so its controlled by upstream

#

so our default branch just perfectly reflects their state of things, we dont get to choose when we make new real releases and just keep in line with their choices

cobalt sparrow Feb 23, 2025, 10:56 PM

#

@paper juniper could this be useful? https://github.com/marketplace/actions/fork-sync

#

also our Baubles-Expanded fork needs syncing

paper juniper Feb 24, 2025, 4:19 PM

#

hmm its nice that its automated but im not sure that i like that it would basically "wrap" every upstream commit with a pr on our repo instead of just syncing directly

cobalt sparrow Feb 24, 2025, 4:21 PM

#

paper juniper hmm its nice that its automated but im not sure that i like that it would basica...

we can change the merge method

#

can have it rebase instead

paper juniper Feb 24, 2025, 4:21 PM

#

yeah thats true

#

ill have to play around with it some on a random repo of mine to check it out

cobalt sparrow Feb 24, 2025, 4:22 PM

#

kk

cobalt sparrow Mar 13, 2025, 7:27 AM

#

@silk kindle should we be fine to set our EFR fork's default branch to the gtnh branch so that we can use our workflows?

paper juniper Jun 2, 2025, 1:55 PM

#

@cobalt sparrow what happened with EFR. it seems completely against everything discussed here and in prior conversations

#

now we are reviewing and merging cloned PRs on our fork, it looks like we are trying to take the repo over from roadhog, i dont understand it

cobalt sparrow Jun 2, 2025, 1:56 PM

#

Changing it to more how we handle MUI2

#

I already talked it over with Roadhog

#

Our prs will be tested in our repo, then I will pr them back to upstream

paper juniper Jun 2, 2025, 1:56 PM

#

so we are just fully using our fork, and not ever using upstream releases in the NH pack

cobalt sparrow Jun 2, 2025, 1:57 PM

#

Depends on timing since he has been working on rewriting upstream

paper juniper Jun 2, 2025, 1:57 PM

#

@foggy snow for visibility

#

and @sudden basin

foggy snow Jun 2, 2025, 1:58 PM

#

i'm lost kekw

paper juniper Jun 2, 2025, 1:58 PM

#

im pretty lost too

cobalt sparrow Jun 2, 2025, 1:58 PM

#

tldr: just use our fork

foggy snow Jun 2, 2025, 1:58 PM

#

if RoadHog knows we don't try to steal his mod, then it's fine i guess

cobalt sparrow Jun 2, 2025, 2:00 PM

#

yeah, i basically just have to ignore any changes we make to the buildscript

paper juniper Jun 2, 2025, 2:00 PM

#

over time this will quickly become just two separate mods

#

and roadhog is really okay with us basically deciding what is going in the mod with upstream syncs?

#

i really dont like this PR cloning business either

#

should I just close my upstream PR if thats how we are doing it then

#

or do i need to now address a review in our cloned PR by committing to the upstream PR then resyncing again

cobalt sparrow Jun 2, 2025, 2:02 PM

#

Well how do you suppose I do it?
Without having prs on our fork, it was hard to keep track of what was merged and what wasnt

paper juniper Jun 2, 2025, 2:03 PM

#

what was the issue with upstream PRs, then a fork of ours with a disposable GTNH branch that we could test our own PRs in if we felt the need, and then contributing reviews that roadhog can see to the upstream PRs on the upstream repo

#

we can still make our own GTNH releases if the need arises

#

this is like what we do with tgregworks

cobalt sparrow Jun 2, 2025, 2:05 PM

#

We can go back to that once roadhog completes the rewrite

paper juniper Jun 2, 2025, 2:05 PM

#

what is actually preventing us from doing that now? the repo is stalled sure, but thats what a gtnh branch is for

cobalt sparrow Jun 2, 2025, 2:06 PM

#

i think it was related to the workflows and the weird gradle setup roadhog uses

#

i kept an upstream branch that matches upstream so all that is changed is gtnh = master now

paper juniper Jun 2, 2025, 2:07 PM

#

and this rewrite includes redoing the gradle setup? or how will that help in that regard

cobalt sparrow Jun 2, 2025, 2:07 PM

#

the rewrite is to incorporate HogUtils

#

no idea on what else

#

Nuke it from the pack, idc

paper juniper Jun 2, 2025, 2:08 PM

#

i dont really see how that rewrite changes anything about how we can manage the repo

cobalt sparrow Jun 2, 2025, 2:10 PM

#

Boud didnt help when he merged reference prs
https://github.com/GTNewHorizons/Et-Futurum-Requiem/pull/11

GitHub

Add config option to remove boat rotation lock by Caedis · Pull Re...

Ref: Roadhog360#623

#

https://github.com/GTNewHorizons/Et-Futurum-Requiem/pull/8

GitHub

Remove dead code by Caedis · Pull Request #8 · GTNewHorizons/Et-F...

Ref: Roadhog360#598

#

that was what started it

paper juniper Jun 2, 2025, 2:11 PM

#

i understand im not trying to pin blame

#

im just trying to understand why things are the way they are rn

#

sorry if im coming across overly blunt

silk kindle Jun 2, 2025, 2:13 PM

#

Because roadhog took on an overly ambitious refactor, doesn't want to merge prs during that, and got burnt out.

#

So as to avoid waiting on him forever, temporarily use our branch until he's done and accepting prs again

paper juniper Jun 2, 2025, 2:15 PM

#

do we really need to do all of this though or can we treat it like a standard fork with an active upstream with the caveat that we will pull our own PRs to a gtnh branch for making gtnh-testing tags

#

that then may just so happen to find their way into a stable if things take as long as they seem like they will

silk kindle Jun 2, 2025, 2:15 PM

#

We should sync back upstream when he's done

#

There's no reason steady state to ship a fork instead of his on cf/mn etc

paper juniper Jun 2, 2025, 2:16 PM

#

wdym? i dont understand the last message

silk kindle Jun 2, 2025, 2:17 PM

#

Diverging long term isn't acceptable. They should have control over their mod and distribution. We shouldn't take downloads away from them unless it's in coordination with them for something that's hopefully one off

paper juniper Jun 2, 2025, 2:17 PM

#

yes fully agree

silk kindle Jun 2, 2025, 2:18 PM

#

Once his refactor is done, we should sync back. If we use our fork for nightlies that's fine. But ideally any major release is done in coordination with them

cobalt sparrow Jun 2, 2025, 2:18 PM

#

but if he is not ready, then there is nothing we can do

paper juniper Jun 2, 2025, 2:19 PM

#

well first of all i think we need to make sure he is okay with us shipping a version other than his in this stable, has that been discussed already?

silk kindle Jun 2, 2025, 2:19 PM

#

I believe caedis did, yes

cobalt sparrow Jun 2, 2025, 2:19 PM

#

Yes, several times

#

and I have made it clear to him that we will sync back once his repo is ready

#

we are basically using our repo to test the prs

#

that is still true

#

We have so far added nothing new that isnt in the prs he has

paper juniper Jun 2, 2025, 2:20 PM

#

ok, then if thats what we're doing we either need to keep up with upstream only PRs and pull them into a gtnh branch like before, OR we need to only PR to our own with the plan of syncing again later like you said. i dont think this system right now of doing the same PRs in both makes sense

cobalt sparrow Jun 2, 2025, 2:21 PM

#

I did that just for keeping track of merged prs in our fork

paper juniper Jun 2, 2025, 2:21 PM

#

im left here with a PR for upstream and a code review on your copy of my PR and i have no idea what im supposed to do to address it

cobalt sparrow Jun 2, 2025, 2:22 PM

#

Make the change upstream and I pull it down

paper juniper Jun 2, 2025, 2:23 PM

#

ok then going forward i think we need to announce to people to review the upstream PR and not our fork, it kind of reduces the point of PRing upstream if we are only giving roadhog half the story in his repo

cobalt sparrow Jun 2, 2025, 2:23 PM

#

almost like I referenced the upstream pr for a reason

paper juniper Jun 2, 2025, 2:24 PM

#

well people didnt follow it, though i cant really blame them for not knowing what to do here

cobalt sparrow Jun 2, 2025, 2:24 PM

#

fair

paper juniper Jun 2, 2025, 2:25 PM

#

ok so let me type up my understanding of all of this now

sudden basin Jun 2, 2025, 2:25 PM

#

cobalt sparrow almost like I referenced the upstream pr for a reason

Ref: <link> is not very clear tbh

#

it could mean anything

silk kindle Jun 2, 2025, 2:26 PM

#

Feels like a longer lived pre/dev Branch?

paper juniper Jun 2, 2025, 2:27 PM

#

efr is stalled because of reasons unrelated to nh. because of this, in the mean time we are going to be merging PRs into our fork's main branch so that we can get the changes needed in efr for 2.8. this has been communicated with roadhog and he is fine with us using our own version of efr for this stable. PRs should still be made upstream, and PR reviews should also be done upstream. once a PR is deemed as ready for merge in upstream by a gtnh dev, then we can include it in our main branch. once things are caught up upstream, then we can restore things to the way we maintain normal active upstream repos

#

is this accurate?

cobalt sparrow Jun 2, 2025, 2:28 PM

#

sure

paper juniper Jun 2, 2025, 2:28 PM

#

do we really need to copy the PRs in this description though?

#

at least pre-emptively

#

when its time for us to merge, sure

cobalt sparrow Jun 2, 2025, 2:28 PM

#

Its mainly so that upstream has a line back to the pr that was tested

paper juniper Jun 2, 2025, 2:29 PM

#

well in the description i gave, the upstream pr is the one that was tested

cobalt sparrow Jun 2, 2025, 2:30 PM

#

I think I was running into a git issue related to pulling an upstream pr and then trying to merge it into our gtnh branch

#

mismatched histories i think

#

this was after it had already been merged before

paper juniper Jun 2, 2025, 2:30 PM

#

did you try to rebase merge?

cobalt sparrow Jun 2, 2025, 2:31 PM

#

cant remember

#

i tried to mainly stick to squash merges

paper juniper Jun 2, 2025, 2:31 PM

#

i think its okay to clone the PR to make it simpler to merge if that workflow just works better

#

but i think having them open and lingering is just inviting problems

#

like opening the pr on our fork once the upstream real pr has been "approved for nh" or whatever, just to then immediately merge

#How we handle Upstream Repos in the future?!