Open alexeyOnGitHub opened 4 years ago
Here is my current plan for myself. For the Civ6-UIFiles repo, I would leave as is in my repo. Reason being this structure was what Azurency was comfortable following and should he come back later I would like to have things in a way where he can pick up easily. My guess for his structure being this way is to imitate how the game would see the files under the different conditions (base game, expansion1, expansion 1+2).
For a more "me friendly" structure that should also be future proof, I was going to create a new repo with the structure I proposed and build the history manually. I was planning on using this to learn a bit more about git, I learn better doing things hands on. I'm pasting the structure I was thinking of following below.
Civ6InstallLocation\Base\Assets\UI -> master\Base\Assets\UI Civ6InstallLocation\DLC\Expansion1\UI -> master\DLC\Expansion1\UI Civ6InstallLocation\DLC\Expansion1\Expansion1.modinfo -> master\DLC\Expansion1\Expansion1.modinfo Civ6InstallLocation\DLC\Expansion2\UI -> master\DLC\Expansion2\UI Civ6InstallLocation\DLC\Expansion2\Expansion2.modinfo -> master\DLC\Expansion2\Expansion2.modinfo Readme file for instructions on how to update repo -> master\Readme.md
in that case, is it feasible to merge "expansion2" and "expansion1" branches into master, and only then move files around? they must keep their history this way. assuming that merging itself it practical. this may be the easiest way.
I think doing merge first would overwrite of some of the files we want to keep around. If we want to try this approach I would go with doing the moves within the expansion1 and expansion 2 branches first (assuming that merge wouldn't also move stuff, but assuming merge moves stuff then I would try a copy with history in each branch first, if there is such a thing). So the files in expansion1 that we want to move into master\DLC\Expansion1 should first be moved/copied into expansion1\DLC\Expansion1, same with expansion2. After that we can merge into trunk.
I personally would like to try my idea in the last post first, since that feels like less headache at this point. I might re-think that after I try it out or learn more about git, but for now it seems like less headache.
moving files inside branches first sounds good to me. then we can merge them to "master". thanks a lot for exploring this!
I believe it is best to resolve this one way or another before we merge anything else here. the PR already merged should either be reverted, or (maybe better) this fork can be dropped and re-created.
I think we may be better off creating our own repo and just starting anew, if we need history we can refer to Azurency's branch (or a copy of it).
I spent a good bit of time confused on the setup, but basically master branch are the files you'd find in Base\Assets\UI, and the expansion branches are those same files found in Base\Assets\UI with the expansion files mixed in.
This makes for some inconsistencies, though not wide-spread, but it does make a merge and keep file history relatively impossible for those affected files. A few files in the Civilopedia folder are like this - compare CivilopediaPage_Building.lua for example. Master Expansion2
The two files split after the Feb 9 2018 check-in, and currently don't match one another in these two branches.
However, the version found in Master matches the version in Base\Assets\UI\Civilopedia. The version found in Expansion2 matches what you find in DLC\Expansion2\UI\Civilopedia. Same file name as far as Git is concerned, and even if GitHub properly reported file history, it would be tricky to maintain the history on both while binplacing them into their respective locations in Alihulmuda's proposed layout.
There's other things like the files found in gitroot\Replacements folder in the expansion branches. It's confusing - taking another example - CityStates.xml exists in 2 places in expansion2 branch (PartialScreens and Replacements folders), but only 1 place in master (PartialScreens).
I like the proposed layout, btw. It makes sense and having those .modinfo files would be handy.
GitHub's organization invite is weird - I kept looking for it in my profile, rather than thinking I needed to go to that organization and see that I had been invited. Anyway, I did manage to join.
so, just to clarify - Civ6-UIFiles repo has the original game files, not something that people modded, right? what is the benefit of having any folders structure that is different from the original one? if we do need a non-original folders structure, then I suppose each possible layout would help us achieve some goals. what are they? e.g. layout X allows to support all game expansions at the same time (just speculating), layout Y allows to do Z, etc.
not sure what the benefits are yet. if there is no clear benefit, then I would just go with the original folders structure, maybe even starting from scratch as @the-m4a said.
For the potential benefit of having the current Civ6-UIFiles structure, we would have to ask Azurency. Parts of it kind of make sense but other parts don't.
My plan from the beginning has been to mirror the games filesystem structure, lack of experience with git and some free time (when I'm not distracted by Civ6) is what's slowing it down. I just started reading up on git and GitHub yesterday. So hopefully today I'll start experimenting with git repos on my account and then I'll work on building a new UI files repo from scratch based on the history of the Civ6-UIFiles repo. I'm hoping to find some way to use patch files to make the process less error prone, but I'm still reading up on things.
Alexey your understanding is correct - the Civ-UIFiles repo has the unmodified game files. The structure does not follow the file layout found in the game itself, which is confusing. Alimulhuda’s proposal follows that format.
I mentioned in a different thread: using ‘git mv’ to move files to the location we want results in the history of that file being lost, but only in the github web page. Using the command line Git would still allow to see that history, but I think that losing the history in the github web page makes is a bad thing as that’s where most people would look.
There’s less than 10 commits that Azurency made to the various files, so manually rebuilding the history with the files in a location that resembles the game files is doable. If we want that history and want it visible that may be the best thing to do
I've created a new repo with as much history as I could preserve over here https://github.com/alimulhuda/Civ6-UIFiles-Restructured
If you all are okay with the way things are we can fork it into this place and continue maintaining it here.
I will rely on your opinion here, guys.
Didn't see this until just now. New Repo is probably the way to go. Will check it out now but I would wager it's good! Thanks for doing that @alimulhuda!
@the-m4a I've forked the restructured repo into the civfanatics organization. https://github.com/civfanatics/Civ6-UIFiles-Restructured Regarding your comment from the other thread, it should be up to date with the current version. If you get a chance do a quick folder compare just as a sanity test. The restructured repo follows the game folder structure so comparison should be simple. When the patch comes out I will update the restructured repo. I'm thinking I'll stop updating this one.
@alexeyOnGitHub I've forked my restructured repo into the organization https://github.com/civfanatics/Civ6-UIFiles-Restructured. I didn't realize it would make me admin by default and I have no idea if I should be doing anything special for the permissions or any other settings. So I've added you as Admin, and when you get some time could you set it up the way it's supposed to be.
hey guys, we need to address the issue with losing git history (https://github.com/civfanatics/Civ6-UIFiles/pull/1)
it is not too late to drop the repo and fork it again, then figure out a merge-move-files-etc solution that would preserve the history. we should do it before we merge anything else on top.
let's say we go back to the commit before the merge happened. we can discard everything that happened after it (the recent merge). in that case, is it feasible to merge "expansion2" and "expansion1" branches into master, and only then move files around? they must keep their history this way. assuming that merging itself it practical. this may be the easiest way.