The problem: sty+ct+ap is currently partially formatted with DOS style line endings, CR+LF; our branches have UNIX style line endings, only LF. Any straight merge gives conflicts of the form "the whole file has changed".
I have a plan, successfully tested. It requires cooperation to be permanently successful.
In our source branches, there is now an .editorconfig file that defines the UNIX style as the style to use, among other things: Four spaces for C++ indentation, tabs for XML and Makefiles. Not because I prefer that, but because that's what the code uses, and changes are complicated.
Many editors respect .editorconfig out of the box, most others have a plugin. So as soon as that file is in sty+ct+ap, there should be no more problems.
(There is the problem that the vscode extension does not yet support charset, so it won't know it needs to switch to latin1 for the language text files.)
Thankfully, getting there is simple. Take the current state of sty+ct+ap, apply the dos2unix program on all code files. Commit that. Merge legacy_0.2.9. Git does not care about the DOS style line endings in in-between revisions, only the last common state and the two end states, so only real conflicts need to be resolved.
The result of the test I did some way back is here: https://gitlab.com/zmanuel/armagetronad ... type=heads
One reformat commit, one merge, done. You have to scroll down to Sept 15 to get the last sty+ct+ap revision, just in case you are wondering.
I'd redo that work now, more CRs have appeared and I'd like the history to be as clean as possible.
And I'd elevate the result to a higher status; I'd let the regular CI system make builds for them and publish them along the base ones. As there are now significant client additions, that only makes sense.
Merging legacy_0.2.9 and sty+ct+ap again
Re: Merging legacy_0.2.9 and sty+ct+ap again
Scratch that waiting, I just did the process again, there are not too many conflicts:
https://gitlab.com/zmanuel/armagetronad ... type=heads
https://gitlab.com/zmanuel/armagetronad ... type=heads
Re: Merging legacy_0.2.9 and sty+ct+ap again
This is my write up (with some assumptions) as to what happened: a slightly dumb text editor (probably the codeblocks in-built text editor) was used in a lot of commits which supported mixed line endings but did not autodetect the line endings used for some reason. Whenever any new lines were added, it would've used CRLF while leaving the rest LF. When I hacked away at the source, I was at first using (I believe) the Kate text editor which apparently did not support mixed line endings. However its autodetection of line endings would see CRLF line endings on some lines (even though the file was always more LF than CRLF) and just convert the whole file to CRLF line endings. This had the effect of making it the diffs look like you are erasing the whole file and replacing it with the exact same contents for (in the most extreme case) 99% of the file as LF gets changed to CRLF, but showing no change for the 1% of lines where the line endings are already CRLF. (example). I was unsure of why diffs looked like that at the time, but later when I did figure it out, I looked for text editors that supported mixed line endings in the same file so that it wouldn't occur. I was actually using Notepad++ under WINE for a while exclusively for working on +ap, while still using Kate for most everything else, until eventually discovered Geany also supported mixed line endings and switched to that.
Most sensible text editors designed for code should really try to autodetect line endings, tab types, and encoding. Chances are high that a text editor that doesn't have the option for autodetection for any of that also hasn't implemented .editorconfig support out of the box. And someone who uses a text editor that doesn't implement either of those may not set the text editor to the correct settings or install the plug-in needed (even if it's mentioned somewhere, who wont read it?). So, I'm not truly convinced having an editorconfig would actually solve the problem, but it's probably better than nothing.
By the way, this is also the reason why gServerBrowser's aspect ratio fixes did not merge cleanly into 0.2.9; I believe the copy in +ap had been converted entirely to CRLF line endings while the copy in 0.2.9 was LF line endings. Yeah, the way the server browser looks in 0.2.9.1 still bothers me, but arguably that way is better for ultrasupermegawide screens anyway.
Anyway, instead of converting the line endings myself or attempting to merge a git branch into bzr, I downloaded the patch from that gitlab branch and applied it against the +ap branch. And then, of course, did a merge from 0.2.9. Yeah, I'm still using bzr... I'm not unwilling to switch to git, but I could never figure out a way to do so smoothly where everything continues to be synced between git and the ~armagetronad-ap -owned bzr repo. I tried running the git<->bzr bridge myself but it did not actually work for me, instead consuming all system memory until I killed the process. So, I gave up and just continued using bzr. I'm not actually sure if it would've created a result that was completely mergable with the other armagetronad git repositories anyway; that would be quite important. Ideally compatible with the +ap branch in the main gitlab as well.
Enough rambling for now though. Basically, task done. Now, to hope merging the line ending changes into branches based on +ap goes well...
Most sensible text editors designed for code should really try to autodetect line endings, tab types, and encoding. Chances are high that a text editor that doesn't have the option for autodetection for any of that also hasn't implemented .editorconfig support out of the box. And someone who uses a text editor that doesn't implement either of those may not set the text editor to the correct settings or install the plug-in needed (even if it's mentioned somewhere, who wont read it?). So, I'm not truly convinced having an editorconfig would actually solve the problem, but it's probably better than nothing.
By the way, this is also the reason why gServerBrowser's aspect ratio fixes did not merge cleanly into 0.2.9; I believe the copy in +ap had been converted entirely to CRLF line endings while the copy in 0.2.9 was LF line endings. Yeah, the way the server browser looks in 0.2.9.1 still bothers me, but arguably that way is better for ultrasupermegawide screens anyway.
Anyway, instead of converting the line endings myself or attempting to merge a git branch into bzr, I downloaded the patch from that gitlab branch and applied it against the +ap branch. And then, of course, did a merge from 0.2.9. Yeah, I'm still using bzr... I'm not unwilling to switch to git, but I could never figure out a way to do so smoothly where everything continues to be synced between git and the ~armagetronad-ap -owned bzr repo. I tried running the git<->bzr bridge myself but it did not actually work for me, instead consuming all system memory until I killed the process. So, I gave up and just continued using bzr. I'm not actually sure if it would've created a result that was completely mergable with the other armagetronad git repositories anyway; that would be quite important. Ideally compatible with the +ap branch in the main gitlab as well.
Enough rambling for now though. Basically, task done. Now, to hope merging the line ending changes into branches based on +ap goes well...
Re: Merging legacy_0.2.9 and sty+ct+ap again
About editor auto-detecting the desired formatting standards: That is what your Kate did, apparently, only that it did not conclude mixed line endings would be tolerated... Really, editors should just leave lines you don't edit alone, and only apply whatever settings they divined (via user settings, project settings, .editorconfig or autodetection) on the line you touch.
git-clang-format is a good example for such a behavior: It applies clang-format on all of the lines you have local git changes in. The workflow is slightly awkward if you only want to commit part of your changes.
You can apparently configure giit on a per-repository basis to apply line ending transformations. That would have also prevented the kerfuffle... had you been using git. https://docs.github.com/en/get-started/ ... ne-endings No such thing seems to exist in bzr.
git/bzr syncing: Yeah, that is incredibly fiddly. The one thing you need to get right is the git-remote-bzr version, I use my own branch for everyting:
https://github.com/zmanuel/git-remote-bzr The version determines how bzr revisions are turned into git revisions, mostly how the metadata is transferred. One deviation there and your bzr branch is going to turn into a completely different git branch.
The next issue is that most new revisions were done in git, then transferred over to bzr. It is not 100% guaranteed that they would produce the same git revision back. That can't be avoided in git-remote-bzr, it is an issue with how git exports and imports data for the git-remote mechanism.
And, of course, as bzr generates its revision unique identifiers randomly and not from the content, mapping from git to bzr will give you different bzr branches if you do it twice independently.
Against all three problems, there is help: the marks files. They are maps from already established equivalences between git and bzr revisions. They are stored locally in the repositores you use for syncing. I let my syncer export them: https://download.armagetronad.org/~baza ... ron/marks/ I never actually checked how one would import them, though... they're for backup purposes only, I suppose, because even if you use them to kickstart your own syncing repository, any new revisions from upstream won't be included.
Have you tried interacting with git repositories with breezy, the new replacement for bazaar? That is no solution to the sync problem, but it may provide a friendlier interface. Maybe that can ease you over. The thing is, I really don't know how long the git/bzr syncing is going to continue to work. It's based on Python 2, and I already had to jump some low hoops to get everything installed on the build server when the raspi it was on previously decided it did not want to boot any longer.
And, why don't you point me to the branches you want synced and I just add them to my configuration? It's just a line somewhere for me, and no trouble with future changes. I understand if you want to be as autonomeous as possible, though, so if you want to set up your own syncing, with all the risks (well, worst case, if you stick to working with bzr for now, the git branch you produce will diverge from upstream), tell me what operating system you want it to run on and I'll try to put together a guide. It's just four ingredients to install, git, python2, bzrlib, and git-remote-bzr.
git-clang-format is a good example for such a behavior: It applies clang-format on all of the lines you have local git changes in. The workflow is slightly awkward if you only want to commit part of your changes.
You can apparently configure giit on a per-repository basis to apply line ending transformations. That would have also prevented the kerfuffle... had you been using git. https://docs.github.com/en/get-started/ ... ne-endings No such thing seems to exist in bzr.
git/bzr syncing: Yeah, that is incredibly fiddly. The one thing you need to get right is the git-remote-bzr version, I use my own branch for everyting:
https://github.com/zmanuel/git-remote-bzr The version determines how bzr revisions are turned into git revisions, mostly how the metadata is transferred. One deviation there and your bzr branch is going to turn into a completely different git branch.
The next issue is that most new revisions were done in git, then transferred over to bzr. It is not 100% guaranteed that they would produce the same git revision back. That can't be avoided in git-remote-bzr, it is an issue with how git exports and imports data for the git-remote mechanism.
And, of course, as bzr generates its revision unique identifiers randomly and not from the content, mapping from git to bzr will give you different bzr branches if you do it twice independently.
Against all three problems, there is help: the marks files. They are maps from already established equivalences between git and bzr revisions. They are stored locally in the repositores you use for syncing. I let my syncer export them: https://download.armagetronad.org/~baza ... ron/marks/ I never actually checked how one would import them, though... they're for backup purposes only, I suppose, because even if you use them to kickstart your own syncing repository, any new revisions from upstream won't be included.
Have you tried interacting with git repositories with breezy, the new replacement for bazaar? That is no solution to the sync problem, but it may provide a friendlier interface. Maybe that can ease you over. The thing is, I really don't know how long the git/bzr syncing is going to continue to work. It's based on Python 2, and I already had to jump some low hoops to get everything installed on the build server when the raspi it was on previously decided it did not want to boot any longer.
And, why don't you point me to the branches you want synced and I just add them to my configuration? It's just a line somewhere for me, and no trouble with future changes. I understand if you want to be as autonomeous as possible, though, so if you want to set up your own syncing, with all the risks (well, worst case, if you stick to working with bzr for now, the git branch you produce will diverge from upstream), tell me what operating system you want it to run on and I'll try to put together a guide. It's just four ingredients to install, git, python2, bzrlib, and git-remote-bzr.