[sv3tli0]

Hi

At the moment we have just 1 base repository: bcit-ci/CodeIgniter which contains all the code issues / pull requests / commits and etc.
From many others git based projects we can think for splitting a little bit the framework into components/drivers and to keep the current bcit-ci/Codeingiter as Framework repository.

There are many things which are or can be stand alone as Session / Cache / Database / Logs / CORE..
Those things can be in a separate repositories for each component. 
And at the original bcit-ci/CodeIgniter we can keep the current complete variant of the framework.

Its not going to be hard of support. The only difference will be merging each component after a commit is confirmed as stable and tested inside the main repo.

How ever the current way is not wrong either so we can leave it as it is.

I wont start pull as this is more CI council decision..
What do you think about this ?

[gadelat]

Personally I hate splits like this, it's hard to keep track of changes.

[sv3tli0]

Personally I hate splits like this, it's hard to keep track of changes.

There are different ++ and -- in those splits I agree.. 
How ever you have always a final CI framework repo which will contain all changes which are merged inside it.. So its not big difference from now. 
And normally you should look at documentation instead at the git repo for information

How ever if you have stand alone packages with tests and a lot less code inside it, it can be a lot easier to make changes in it fast clear without any problems related with branches and commits (if you are too back or far away from master).

[gadelat]

Lot easier? No problems? What happens when you need to touch different files spread across these repos in your commit? Mess. Also, I don't see a reason to do this. Do you think current system is hard to navigate or what? I don't think so. Tell me what are those ++

[sv3tli0]

Lot easier? No problems? What happens when you need to touch different files spread across these repos in your commit? Mess. Also, I don't see a reason to do this. Do you think current system is hard to navigate or what? I don't think so. Tell me what are those ++

Please read thread title : GIT organisation

Sorry but your Look over the things is not right. 1 commit should not touch 2 components at the same time. 
When you are working over Core you don't add some extra fields in the Sessions just to be easier for you.
Even its better to have such Session repo where to add the extra elements. After that to run the Session repo tests. And just after that to use it at the core.
The current system is END line of the framework as its provided to developers but how you will build it is other thing..
And once again - you will have the same repo view which you like so much.. With all commits and etc.. So you can check all elements and etc..

Of course the how structure has to be discussed if CI staffs decide to do that at all.. 

[mlantz]

If we run with GIT separation we have the ability to have a clean use case of composer loading, this way we can similar to Laravel separate the framework components from the application structure. Means MUCH easier updates etc

[Razican]

If we did a split, I think it should be splitting the documentation, and giving it its own repository. I think that not everyone downloading the repository needs to download all the docs, taking into account that they can be found online.