3 ms·

If there was any value at all in renaming it to main, it was preventing people from being reminded of the unhappy concept of slavery. I don't think one ban is m

If there was any value at all in renaming it to main, it was preventing people from being reminded of the unhappy concept of slavery. I don't think one ban is more conceptual than the other, if there's a difference it's that scrubbing an unhappy concept from research is more pragmatically damaging than scrubbing it from nomenclature - not because one's morally better, but because the former is more difficult to evade.

zzo38computer 2y ago
I disagree. If people want to call it "main" that is OK and I do not have an objection, although slavery and racism is not a part of it. Using different words does not solve slavery or racism or anything like that. There are some minor advantages of "main", but many of the previous objections to the change are invalid and based on ignorance of the working of git; once I figured out how it works, I do not have an objection, since you can call the branches whatever you want to do anyways, and the names "master" is not something special anyways except for what it is called if you do not otherwise specify a name. Furthermore, existing repositories on GitHub are not automatically changed, and they added function for renaming branches (which can be useful for other reasons too), so for these reasons I think what they did is good. Some minor benefits of "main" is that it is shorter than "master" and starts with the same two letters as "master" (which might sometimes matter, e.g. if the branch names are listed in alphabetical order and you want to find them in the list). These benefits seems like only minor benefits to me, though. However, my opinion about the change in SQLite, changing a table name from SQLITE_MASTER to SQLITE_SCHEMA, is different. I think that the new name better describes what it is for (it is the table for the schema of the database), but I would not have made that change, since it can cause problems. They did consider some of them (such as authorizer callbacks, which is something that I had thought of too before I knew what they did about it), and work around them, but that just makes it more messy, so I still think it was a bad idea, but now it is done and it would not be good to undo this change, either. If I was in charge of it I would have deferred the change until SQLite4, rather than changing SQLite3. (There is also the issue of the SQLITE_SCHEMA error code.)

zzo38computer 2y ago

I disagree. If people want to call it "main" that is OK and I do not have an objection, although slavery and racism is not a part of it. Using different words does not solve slavery or racism or anything like that. There are some minor advantages of "main", but many of the previous objections to the change are invalid and based on ignorance of the working of git; once I figured out how it works, I do not have an objection, since you can call the branches whatever you want to do anyways, and the names "master" is not something special anyways except for what it is called if you do not otherwise specify a name. Furthermore, existing repositories on GitHub are not automatically changed, and they added function for renaming branches (which can be useful for other reasons too), so for these reasons I think what they did is good. Some minor benefits of "main" is that it is shorter than "master" and starts with the same two letters as "master" (which might sometimes matter, e.g. if the branch names are listed in alphabetical order and you want to find them in the list). These benefits seems like only minor benefits to me, though. However, my opinion about the change in SQLite, changing a table name from SQLITE_MASTER to SQLITE_SCHEMA, is different. I think that the new name better describes what it is for (it is the table for the schema of the database), but I would not have made that change, since it can cause problems. They did consider some of them (such as authorizer callbacks, which is something that I had thought of too before I knew what they did about it), and work around them, but that just makes it more messy, so I still think it was a bad idea, but now it is done and it would not be good to undo this change, either. If I was in charge of it I would have deferred the change until SQLite4, rather than changing SQLite3. (There is also the issue of the SQLITE_SCHEMA error code.)