GIT: Quality of life improvements#550
Conversation
CMakePresets.json are intended to be shared and committed; CMakeUserPresets.json are intended to be per-user, not shared and not committed.
|
I fixed the line endings throughout ZIMH on the day that I forked it; fixing all the line endings in SIMH would take half an hour and would make everyone happy. If the settings are correct, then people on Windows get Windows line endings for text files and people on POSIX systems get POSIX line endings. It's not particularly difficult to do it. |
|
The legacy repos (simh/simh and open-simh/simh) have had universally CRLF line endings tabs expanded to spaces since the earliest days of the simh project (25+ years). Changing essentially every file has been decided by all the interested parties to be too much to change. zimh is your personal repo, so do as you please. |
SIMH is not your repo either. You turned the original SIMH into closed source in a tiff, destroyed a community that had been operating peacefully for years, forced the creation of the current OpenSIMH, and show up in the comments of this repository acting as though you are a leader of this project when you are not a member of its steering committee, do not have commit access, and are not a decision maker here. Your pretense that you are somehow speaking for the project is galling. As for the substance: it will cause literally no pain to anyone to fix the line endings and will make everyone happier. It is true that SIMH is not a project I lead and that I hard forked it in despair that it would ever fix itself, but there is no rational reason not to use the built-in git handling of line endings. It means that every platform has a checkout that suits the people using it. |
In fact simh/simh absolutely is my repo. I created it some 15+ years ago after contributing to Bob Supnik's v2 and v3 simh for some 10 years before that. Ever since the project was formed, the author of a simulator or some core code was always the primary party to address and fix problems with code that they authored. What led up to the schism was a problem that a user encountered with how he was using simulator disk data that he was using completely outside of any simh simulator. He raised the issue after it the code causing his problem was in the codebase for some year and a half. Since I wrote the code in question, project convention would have it that I would be the one to address the problem. I provided various ways (and even more since then) to address his problems so that anyone could use the disk contents BOTH within running simh simulators AND also for his external use. His insistence that the default behavior must be what he wanted resulted in the steering committee was formed to fork my simh/simh repo into the open-simh/simh repo so that his desires could be the rule. That was certainly their prerogative. During my ruling over the simh/simh repo, I contributed significantly to the PDP11 and VAX simulators fixing bugs, and adding devices and guided the addition of the simulator count from some 23 originally to some 78 simulators. The core SCP code and runtime was expanded from less than 25K lines to over 100K lines mostly by me exclusively. Since the schism, I've continued active development extending and enhancing the core functionality and bug fixing of the code in simh/simh and folding in updates and additions that have occurred to the open-simh/simh repo. And, it is my prerogative to stop contributing my continued developments to others. Therefore, nothing that I have added to the simh/simh codebase can be used in the open-simh/simh codebase (or forks there of) unless I specifically submit such a change via a PR to the open-simh/simh code.
I am absolutely not a member of the steering committee, but since I managed the rules of the project for at least 12 years until the above mentioned issue arose without resistance for anything else, the general rules that had been followed have always been accepted. Meanwhile, you (@pmetzger) and @LegalizeAdulthood, who have never actually had any code committed to either simh/simh or open-simh/simh, come along and are offended when the details of the project conventions are raised. Your history here is very thin. The interesting concept here is that there are significantly less than 10 active simulator developers who might be making changes or creating simulators, while there are possibly thousands of folks who are interested in using them. With the recent problem reports and some simulator bug fixes by @pmetzger, we now have a new simulator contributor. Meanwhile, absolutely anyone (even those in the steering committee or those who agree with them) can use the simulators in simh/simh as long as they not changing how the sim_disk behaviors work.
This line ending subject has been raised several times in the past, and been rejected specifically by others beyond myself. |
|
Mr. Disk License, please stop commenting on all my PRs, bugs, etc. Go play in your sandbox. You wanted to take ownership of everything in your sandbox and that is where you should play. This project was created specifically to get away from you and your dictates. Go away. |
But this is not simh/simh. Perhaps you are not aware of the fact that you do not have commit access to this repository. Perhaps you are not aware of the strife and heartache you have caused to a huge number of people.
This is not the simh/simh repo. You forcibly took over sole control of that repository (if I had been one of the other contributors you would have had a lawsuit on your hands and that would not have been allowed to stand; SIMH is after all not your trademark but rather Bob's) forcing people to create the repository you are currently posting unpleasant messages to potential contributors in.
But this is not your repository. Your repository is simh/simh, you created a problem by closed sourcing a project that had been open source for decades and forcing people to bend over backwards. Please stop bothering people and pretending that you are in charge here.
Again, this is not your repository. You chose to cause heartache and strife. You chose to create trouble where there was no trouble. You caused enormous harm. You should feel deep shame about this. |
Please elaborate how I caused you or anyone else strife or heartache. Please notice that you also don't have commit access to this repository, but you (and I) can freely comment on the issues at hand.
Please explain how I forcibly did anything?
Actually there is no formal SIMH trademark, if you think there is please point at the details where that is registered.
Actually I took nothing away from anyone. All of my contributions before the schism are available to you or anyone else and it is now contained in open-simh/simh. Additionally, as I said, the contents of the simh/simh repo are available for everyone as long as they don't mix it with the changes that forced the schism.
I was indeed sad about the forceful takeover of the repository content to create open-simh/simh (which was fully allowed by the original license). Meanwhile, as the author of many pieces, I have tried to provide non-insulting feedback to proposed changes to code which I wrote and to provide guidance relating to the legacy conventions in the project.
Please elaborate on the specific harm that I caused to you or anyone else. |
|
Go away. Your continued arguing has nothing to do with this PR. Just go away. |
|
It might work better if you ignore comments that you find unhelpful. Getting in an argument just clutters up the PR log, and a bunch of inboxes. |
|
The sooner the PRs get reviewed and merged, the fewer the opportunity for derailing the PR with irrelevant comments and chest thumping. This PR is so small you could've reviewed and either commented on required changes or merged it in the same time it took for you to comment on it. |
|
Though honestly, SIMH should just do what every other project does and allow Git to use the correct line endings for the platform on which the files have been checked out. Everyone is happy that way. It handles things transparently for you. Essentially every project in existence does this, it's the behavior almost everyone expects, it causes no harm and gives people considerable benefit. When you look at the files on Windows you get Windows line endings, when you look at them on Linux you get Linux ones. I don't get why you would do anything else. The fix is quick and easy too; I did the work in minutes. There's a tiny amount of delicacy around text files checked into the repo that are intended for simulated machines and not for the simulation host machine but that's pretty easy to deal with. |
|
There’s just a basic point-of-view difference between “do as needed to keep up to date” and “change as few lines as possible for stability.” It is ideological, and both sides are I think well-motivated by differing goals; I don’t really see that they can ever be reconciled in one repo. So I’m pretty happy to see the zimh fork, and think it’s the right thing here — the modernists (I am one) can finally have some latitude to systematically change/evolve the sources, while the minimum-perturbation-for-maximum-stability folks can continue with that policy in support of their own goals in their fork.Hopefully this lets people just pick where they want to live and we can share enhancements back and forth at will. It may be a little more work to re-tailor them, and there is possibility of feature drift/lag between forks, but worth it IMO to reduce bickering. I think we can all agree that few things are more frustrating than putting a lot of work and care into an enhancement, only to have it rejected wholesale on principle before merge. We’ll have fewer of those sorts of surprises I think if we pre-cluster like minds in separate forks.(Really psyched for rationalized line endings, md docs, the lean in on cmake, systematic adoption of modern C language standard features, etc. in zimh — thanks to the contributors for all this!) —FritzM.
|
|
While that's all well and good, this PR isn't the place for this discussion. The simh mailing list, or if they enabled it, github discussions would be a great place for the conversation. |
|
@pkoning2 What's holding up the merge of this? |
I got confused by the discussion about globally changing line endings. That's possible but it's a policy change. It also makes all files look as completely changed, though in this web interface you can suppress that by turning on "ignore whitespace". |
|
Thanks |
5 participants
.gitattributes,.gitignore,*.cmakeare text files.gitattributes,.gitignoreCMakeUserPresets.jsonThe line endings problem is pervasive through the repository, but I'm only fixing it for these two files.