@TomTsagk No. The IDE simply calls the build system to do its thing and that's it. You can manually use the build system from console. It's generally not the IDE's fault if the build system screws up.
@nwp Years back, when I was using IDEs, I never had to create a build system myself. The IDE would only expect the source files from me, and do the rest. In this case, who controls the build system?
When you say "create a build system" you mean "write a project file", right? Like a CMakeLists.txt or Project.pro or something like that. Yes, some IDEs are able to add and remove files from the list of files in the project files or let you set flags in a menu which they then copy to the project file.
But if a programmer, writes source files for their project, but never make any build system, and the IDE has buttons to build the project, that must only mean the IDE is responsible for any build system that works behind the scenes?
@nwp I use vim, and invoke the build system manually
I can see why someone would use an IDE, but for me its like, when something goes wrong, I want to be 100% sure its my fault, and not one of my tools getting in the way
It feels time-consuming (for me) to encounter a bug, and be 50-50 that it could be my fault or the IDE's fault. To be fair that was when I used IDEs like 5-7 years ago, so I wouldn't be surprised if things have changed
Tell me about it, where the title is like "Are video games dying?" and the first paragraph is the story of how the author was playing video games as a teenager.
I hate git submodules because they are constantly out of sync because things like git pull don't pull submodules. Also you're constantly in a headless branch.
You can always do git pull --recurse-submodules, I know it's more verbose, but the idea is, you don't want to update submodules automatically
Submodules are made in such a way, that you attach a specific version of the attached project to your project, and whenever you update that project, you have to update your project to agree with those changes.
Mmm I believe git pull --recurse-submodules actually pulls to the latest update on that branch, I think there's another command git submodule <something> to update it based on the current commit, but I haven't used it that way before
@trollingchar Basically in your main project, you only save which commit sub1 and sub2 should be in. So you can make one commit where sub1 is on version v1.0.0 and sub2 is on version v1.5.2, with one commit
Then you can make another commit that changes both versions to whatever you want
Regular git checkout doesn't checkout the submodules which causes endless pain on my end. There is probably a flag that makes it behave correctly, but I don't know what that flag is.
@trollingchar You can do git checkout --recurse-submodules, which will checkout all external projects to the commit defined by the current commit of your project
That would be a security flaw, because you'd be pulling code from potentially some unknown person to your machine, just by doing a git checkout or git pull
By default submodules are considered "external projects", so it has minimal "trust" for them, you can always change that, but it protects people that are not aware
someone who has no idea how submodules work, can easily get a project on the machine and keep running git pull every so often, and eventually get malicious code from one of those submodules without being aware of it
revertable, as in ? If you manage to `pull` some unwanted changes, you can always got to past versions
git is meant to live in your "head", which might make it difficult for some people to understand. It has some internal states, and if someone is not aware of them, its hard to follow what it does.
Not saying that submodules are in any way perfect, but they server their purpose
If it saves users from exposing their machines to unknown code, I think its working as intended
git is very customisable, there's nothing stopping someone from creating aliases, if you feel like one flag should always be there, you can always add it
Creating aliases means that you are more experienced to what the tool does, and accept the "responsibility" if something goes wrong
A while ago, Stack Exchange removed "Hot Meta Posts" from Stack Overflow's sidebar (the "Community Bulletin"). To compensate for this algorithmic selection of questions, they gave Stack Overflow moderators the exclusive right to decide what to feature in the sidebar:
tl;dr: We're removing the...
Yeah, but I mean, as far as I'm aware, not much has happened to this SE, so those policies probably changed because of events that happened on other SE sites?
I'm aware the changes affect us as well, that's what feels weird
@Vaillancourt I can understand someone resigning because of some negative reasons, and want to make sure the community is aware, but ideally that shouldn't happen too often, if at all