Best way forward (Git: splitting project in 2)

[Chief of Nothing]

Wondering how the Git masters would tackle this. I have a very large smf project and with the amount of changes required I'm wondering if it might be best to split the project into 2, part A and part B. The 2 parts are intertwined but could be included separately...mostly (part B doesn't rely on part A to function but a user setting in part A (which can not be moved from part A) will prevent some function of smf without part B).

So, would the git masters a) not bother splitting the project in 2 because what would be part A and part B are part of the same project and intended to be included at the same time or b), split the project.

I would need to test part A and part B at the same time (because of that user setting), if that makes a difference. Fortunately I've only just started the part B changes but haven't committed them so could easily stash the changes and pop them onto a new feature branch, I hope.

[Arantor]

Honestly my approach would be to try to refactor all the changes into hook-based mods wherever possible and keep that as a repo on its own - I wouldn't *really* want to play a game of merging from upstream and handling my fixes there and then. Been there, done that.

As far as separating them is concerned, what's the rationale for separation? They seem to have common parts, so make them common? If you wanted to break things up, do so logically by functionality and what parts of the system they touch, rather than anything else - but I wouldn't sweat it.

[Chief of Nothing]

Thanks Arantor,

It's actually a rewrite of some core code for inclusion into SMF, not just for myself. The rationale for the separation was the first part is essentially done, the second part will probably take quite some time and not being a Git master I was concerned it might be hard for others to follow if it's just the one branch and I do a bit of A, then a bit of B, then some more A etc commiting each time.

However, after posting I realised splitting it into two probably won't work considering how intertwined the two parts are so a single branch it will probably have to be.

[Arantor]

The usual rules apply: if they can be separate, separate them into their own feature branches, and if you can make smaller chunks of improvement rather than massive PRs, that's also better.

If you're thinking about some of the changes for integrity checks and/or asset tagging (that was you, right?) I'd definitely want to be talking to the team before investing any serious time in trying to get it into the mainline build for simple reasons that I don't know what the team's plan for 2.2 or 3.0 or whatever looks like. I have strong views in what I think this should look like but I'm not on the team and my opinion doesn't really matter.

E.g. trying to do integrity inclusions on CSS is fine - unless the build process changes totally, which I for example would be a huge advocate of along certain lines.

[Chief of Nothing]

Yes, that's me. The team are interested in what I'm doing as has been said to me, though in the end if it's all rejected then at least I can have a more secure SMF .

Yes, trying to avoid one massive PR is what I was thinking in splitting the project in two, though each would still be big, it would not be possible to do them in small chunks.

As an aside, the integrity checking is only a small part of it. Though I haven't fully worked it out I was going to make the user responsible for generating the hashes if they wanted to use the feature, the build process wouldn't have to be changed.

[Arantor]

I don't think it's a case of being rejected, just trying to ensure work is coordinated so nothing is wasted.

As a general rule, assume users will misconfigure things so for anything security related, do it for them if at all possible.