Dalija Prasnikar

merge --squash (if I am not mistaken, never used it as I am always rebasing) Remotes never have feature branches, if they do they are only secondary remotes, not main ones. So, yes, I want that history preserved. Rebase without fast forward does that. I usually don't commit experimental stuff in branches that will end up being merged. And if I do, then it is because such commits contain some approaches that are not applicable at the moment, but I want them preserved for the future because requirements can change or some missing compiler/framework features might be implemented. Sometimes, some cruft will end up in repo, but there is not enough of that to be a problem.

That part is purely optional. You can do as you please. But when you are merging without rebasing, you also get the whole sausage, unless you squash. Yes, never rebase a public branch is more clearer. That is what was meant with that sentence. It is never call rebase when you are on public branch. In other words when active branch is public branch.

I found this answer on Stack Overflow about merging branch to master. Maybe it will help. https://stackoverflow.com/a/29048781/4267244

That means going through diff list and making sure that all changes are expected changes - changes I intended to make (that does not mean I am rereading every line of code). For instance, first step is making sure that only files that had to change are changed - for instance if I am making changes in for code and I am not touching design and dfm (fmx) file pops in changed files, I will not commit those files and will revert changes after quick inspection. Next I will go through changes I expect and I did make. If I was working on class xyz and something is also changed in abc, well that means something is wrong. Such things don't happen often, but sometimes you mess things up during debugging or leave unwanted artifacts. I don't commit every two lines of code, but logical tasks. If the task is larger, then it can be spread through several commits.

I forgot another extremely important thing. I never commit everything blindly, I always check every change before commiting to avoid accidental errors and changes in files that should not have been changed.

If I am working on a repo in a team then I pull often, otherwise, no - because I know there is nothing to pull How I use Git (modified git flow) I almost always use GUI client - SourceTree - it was best client on OSX at the time, and I got used to it, so I am using it on Windows, too. It has its quirks (every client has) but I never shoot myself in the foot with it master is always production ready develop is development branch both master and develop live on remote (and they are the only ones that live on remote) each feature is new branch, usually very short lived - never pushed on remote, unless they live too long and have to be shared for some reason, but for that I use temporary remote Basic workflow (if working on team) before creating feature branch pull from remote (there will be no merges, because repo is clean - also, I always do pull with rebase) create feature branch from develop a) work on branch, commit... b) if I think there is something new in the repo and I have committed all my feature branch changes, switch to develop and pull with rebase, same with master c) if there were changes rebase feature branch on develop, check if everything works - repeat from a) when work is done on feature branch, pull and rebase feature on top of changes (if there were any), check if it works (if checking takes long enough and depending on potential conflicts with others, pull again, rebase... check...) when all is completed merge feature branch to develop and push to remote If you have problems with workflow, you can setup demo repo and use that to figure out optimal workflow and then apply to real one. If you ever feel like you have messed up something locally, rename (or otherwise backup files you have been working on) repo folder, clone from remote, create new feature branch and copy your changed files back. I said it before, but it is worth repeating. Unless you are GIT DIE HARD, don't use console.

Nope. Memory management is completely different castle. Custom managed records are about ability to use automatic, custom initialization and/or finalization on records and enabling easier implementation of some concepts like nullables. Without automatic initialization/finalization, you can still use records but there are trade offs - you either need to use manual initialization/finalization which is error prone or you need to implement some additional safeguard mechanisms that are more complex and commonly slower than using custom managed record.

I have to say I have trouble visualizing your actual problem with Git workflow (or any workflow). Also, whatever problem you do have I don't think it is related to Git. If your problem are merges, then without Git your would still have problem, you just would not know you have it, until something would not work correctly. Having everything in single repo is a bit odd, but if the parts are really independent then you should not have any issues. Short lived branches and features are actually better than long term feature branches as they create less conflicts - I am not talking about develop and master in that context, but creating some feature branch that takes long time to develop and that changes code other people might change in between. Your main problem seems to be having conflicts in short term features that sound like they are independent. If that is true, then your tickets are not actually independent and working on multiple tickets means adding changes to same files (even though Git is good in merging code) that is usually recipe for disaster (or at least constant merge struggles). To fix that, you should either split offending parts of code to smaller pieces (files) because that will decrease chance of more people working on same code at the same time. If that is not possible, then you need to introduce some other level of discipline here. If there is some common file that needs to be updated, you need to coordinate that change between your developers. Probably the best would be that such common files are not fixed inside ticked feature branch, but as separate feature, then merged back to common base branch (develop) from which everyone can get changes. Next, when I say merge branch, that is not just straight forward merge. For every merge, you need to rebase on top of branch you are going to merge to, make sure your code still works as intended and then merge (if there are changes in that branch in the meantime, you need to rebase again). Same goes for getting changes - if you know there is some change in base branch, you need to take, rebase your feature branch on top of it to apply those changes. For any more detailed advice, you would need to be more exact with description of the problem - for instance, what is exact scenario where you have conflict - like ticket A changes files 1, 2 and 3 and ticket B changes files 1, 4 and 5 and why you cannot separate changes to file 1 or similar.

Don't use AnsiString if anyhow possible. Only if you exclusively work with 7bit ASCII subset then you can safely use AnsiStrings. The reason is that AnsiString - Unicode conversions is potentially lossy. You can lose original data. Using 8-bit strings instead of 16-bit strings can be faster under some circumstances, and they also use less memory. But if you have use case where 8-bit string performance and memory consumption is needed you should use UTF8String instead of AnsiString.

I don't know any particular forums. But, from experience, Git workflow can also be quite dependent on the tool set and existing code base. For instance, some types of files can create huge merge conflicts. So applying workflow that works in one tool set may hit you on the head in another. For instance, Xcode storyboards are nightmare to merge (you can even create unsolvable conflicts as single developer) while handling Android Studio xml UI files is almost trivial. So discussing here is as good place as any other, because you are interested in managing more abstract workflow and when you have that figured out, finding correct Git commands is not as hard.

Not really. This is mostly opinion based question unless there is exact, very narrow problem you need to solve.

The only mention for nullables was in context of custom managed records that are prerequisite for implementing nullables. From that perspective we kind of have nullable support right now in 10.4. But that is far from having full compiler support for nullable types. Nullable types include way more than just defining common RTL type (we don't even have that in 10.4) and one of the things that such support also implies (assumes) is ternary operator. Additionally ternary operator has more broader usage scope than nullables themselves and thus is more interesting, worthwhile feature.

Many features can be nicely added to the Pascal and fit well. https://docs.elementscompiler.com/Oxygene/Delphi/NewFeatures/ The people you talk about are not really Pascal purists, rather people that can't be bothered to learn something new. Delphi never suffered from purists... even its predecessor Turbo Pascal was always innovative and expanded features on top of standard Pascal. We would not have Pascal with objects otherwise. Probably not. Ternary operator is easier to implement than whole nullable support. But like with many other compiler features, someone needs to implement all that - that is the weakest point and the core issue, not "purists" as such.

Guy is beating a dead horse with a stick. Another guy comes along "Hey, your horse is dead, you need a new one" "Nah... I am probably holding the stick wrong"

I never said I didn't ask any questions. Sometimes you need to ask, sometimes you don't. Sometimes you don't get the answer... or the answer is not exactly the one you expected (hoped for), but in such cases forums would not help more either.

If you want to discuss then forum is the right place, if you have specific question then SO is the right place to go. I would not say it is about preferences, but what you need at particular moment. Besides Delphi I am using other tools for development, most notably Android Studio and Xcode. I never needed forums to solve my problems... I could find all the answers on SO and official documentation. Hanging out with other developers and discussing all kinds of things... well, Delphi forums and communities were more than enough for me.

Great colors... make me blind... since color theme matches horrible 10.4 colors, this is all Embarcadero or Idera production...

Not really... official forums were already dead. They basically died when NNTP was dropped.

I voted for it, but I would not hold my breath... this will be either closed as won't fix or will stay open for a long time.

There is no support for release id as such, but every Windows 10 release id has corresponding build number. For instance Creators is 15063. So you can check whether build is 15063 or greater.

There is TOSVersion record in SysUtils that holds OS version information. But you cannot check for particular version by name, you need to know its build number.

You need different architecture to achieve such timing. Timer is not precise enough and even if you can make it precise, there will always be other events that will mess up your timer schedule. You need a some kind of game loop. Basically, you should not rely on timer to calculate and paint your screen, you need to trigger paint event with delta time and based on that time (elapsed from last paint) you will calculate positions and render your screen. Some starting point: https://gamedev.stackexchange.com/questions/651/how-should-i-write-a-main-game-loop

Manual version control is an oxymoron - there is no such thing as manual version control. It is not about something working perfectly or not, it is about manual version control not working at all. All you have are backups of your code at some point in time. Nothing else.

Depending on the feature. If I need to test some general concept and/or feature is not tightly coupled with app I will make separate test project until I figure whether it will work as intended. If feature is tightly coupled with rest of the application I will create new feature branch in that app repository and start from there, even if compiling/running takes time. But, this is what we are trying to tell you, not having VCS is an issue. Because, new feature workflow highly depends on VCS. I know it may seem that learning how to use VCS takes valuable time, but you can get that time back in a week (literally).

It still does not work in 10.4