[OUTDATED] Important - GZDoom repository now uses submodules

[Rachael]

To expand on Graf's point: The repo contains a copy of every version of every file that it has ever stored. So if you store two versions of Titlepic.png that will effectively double the repo's size. If you have 20 versions of it, you have the size of titlepic.png times 20.

Hopefully that helps.

[drfrag]

It helps, i won't update it frequently. If needed i'll delete and reupload them, seems they are stored as long as they're accesible from some place.

[Rachael]

If needed i'll delete and reupload them, seems they are stored as long as they're accesible from some place.

That's not how it works.

Unless you force-push without the history in place, all past copies are stored forever. Deleting them will not help.

And with the way Git works that means everyone who clones gets all past copies, as well, since cloning grabs all history too (unless you specifically choose a shallow clone, but that is *NOT* a default!).

Also - well, should I really be surprised the lengths you will go to just to avoid using submodules when it's still the better solution for you, at least right now? Because of your stubbornness, you're making far more work than you need to in order to solve problems that are nearly non-problems, which creates much bigger problems than the problems you're trying to solve/avoid - and that will be a problem for anyone who wants to contribute to your branch later on.

If you really want to avoid submodules, what I would do is grab the loader commit that includes a bare .pk3 file - then compile WidePix into a zip file manually yourself, and distribute it that way, leaving the source repo with only the bare .pk3 file.

[drfrag]

Because of your stubbornness

No, not really.
That's what i read in an article but it was false.
For my GZDoom clone i'll never update the submodule, the solution here would be to create the new branches from the remote and not from master (default).
For my fork i will update the files only between Widepix releases and they are not big so not that much of a deal. It's good to know this stuff, i'll be careful with binaries from now on.

[Rachael]

As of c12a09c2a the submodule has been removed.

Easiest way to deal with this is to re-clone the repository as it is now, without the submodule.

However, if you have a work tree that has information you don't want to lose, dealing with this change is a lot more complicated. Reportedly, simply removing the old folder that contained the submodule may work.

To prevent Git from making an epicly bigger mess than it could have, the widescreen subproject is now named "wadsrc_widepix" in GZDoom's git root now.

[Graf Zahl]

All I had to do was a hard reset of the master branch on its current commit after pulling to get rid of any residual local data.

Ultimately the experience with using a submodule was an utter disaster, though. More often than not it was causing problems. I certainly will never use this feature ever again.

[Blue Shadow]

For people, like myself, who didn't bother with them when pulling/syncing with upstream, is there anything we need to do? I just pulled from upstream, and there were no issues as far as I can see. Still, I'd like to ask.

[Graf Zahl]

No, if your pull runs through without errors, everything is fine.

[Blue Shadow]

Okay, thanks.