If a patch is in an email then how do you know which parent commit it should be applied to? A patch is not a thing in its own right in isolation; it should come with a specified parent thus identifying a unique code context in which it is correct. Just because it applies cleanly on a branch does not mean it is correct there.
Git email flow vs. GitHub flow
101–110 of 177 posts
Re: Git email flow vs. GitHub flow
#102Re: Git email flow vs. GitHub flow
#103Earlier quoted context omitted.
Yes my bad, it is from a bad copy-paste, you should ignore the last digit.
How do you copy paste something so wrong that it adds a random digit to each number?
They aren't random at all, they are practically in order. It was probably a footnote reference to the bottom of the source article, with a link to each RFC at the footnote.
Re: Git email flow vs. GitHub flow
#104Earlier quoted context omitted.
Case insensitive filesystems are a really bad idea though.
But why ? Why are they a bad idea besides “Windows does it and ‘Windows bad’”? Why is DNS case insensitive (example.com and EXAMPLE.com are the same), but not files (.Xauthority and .xauthority are different)? Case insensitivity lines up with the average user’s expectations. For example, if I’m searching for a file, I want a case insensitive match. Because if I named a file “Resume.txt” and searching “resume” didn’t…
Should that work different for different languages? Imagine the mess. Maybe the file names aren't even written in any human language. Should we use English rules for all languages? Why? What makes English so special that English characters would be normalized, but characters from the native language of the user won't? Wouldn't that trip people up?
Case-insensitive file systems are mostly advocated for by those who only or mainly speak English and aren't aware of how much variety there is in the languages across the globe.
And even in English "us" is a pronoun, whereas "US" is a country.
EDIT: another question: should the normalization rules be changed when the language changes? Break backwards-compatibility?
Re: Git email flow vs. GitHub flow
#105Earlier quoted context omitted.
Yes my bad, it is from a bad copy-paste, you should ignore the last digit.
How do you copy paste something so wrong that it adds a random digit to each number?
The only way I think is that it was a numbered list and they pasted the RFC number before the list number so the list number was actually appended to the RFC number?
Re: Git email flow vs. GitHub flow
#106Earlier quoted context omitted.
Inconvenient to who? There a many things in Linux that anyone who doesn’t use Linux full time finds majorly inconvenient, a lot of the UX around Linux is only intuitive to the 45 year old graybeard. To us 30 year old win DevOps guys Linux isn’t actually that “convenient” out of the box.
19 year old DevOps/Sysadmin here, gonna have to disagree. I can work with Windows, but I hate every second of it. Meanwhile, Linux/BSD is intuitive and easy to get going. Almost like what tools you know impact what you find easy.
Can I ask what’s intuitive about a UX that hides all functionality behind cryptic commands that require reading the mind of the person who made them to know which three letters correspond to the acronym of the command you’re trying to run?
Re: Git email flow vs. GitHub flow
#107Earlier quoted context omitted.
But why ? Why are they a bad idea besides “Windows does it and ‘Windows bad’”? Why is DNS case insensitive (example.com and EXAMPLE.com are the same), but not files (.Xauthority and .xauthority are different)? Case insensitivity lines up with the average user’s expectations. For example, if I’m searching for a file, I want a case insensitive match. Because if I named a file “Resume.txt” and searching “resume” didn’t…
Should that work different for different languages? Imagine the mess. Maybe the file names aren't even written in any human language. Should we use English rules for all languages? Why? What makes English so special that English characters would be normalized, but characters from the native language of the user won't? Wouldn't that trip people up? Case-insensitive file systems are mostly advocated for by those who on…
Thank you gor being exhibit A
If you bothered reading the link, all of these questions have been addressed long ago by folks are are more knowledgeable than either one of us.
The rules are spesific to each language, and are especially neccesary for languages thay have several alphabets. Without this functionality, efficient search is impossible.
This silly, forcefull and uninformed critisism is exactly the kind of behaviour i was talking about.
Re: Git email flow vs. GitHub flow
#108Earlier quoted context omitted.
Case insensitive filesystems are a really bad idea though.
But why ? Why are they a bad idea besides “Windows does it and ‘Windows bad’”? Why is DNS case insensitive (example.com and EXAMPLE.com are the same), but not files (.Xauthority and .xauthority are different)? Case insensitivity lines up with the average user’s expectations. For example, if I’m searching for a file, I want a case insensitive match. Because if I named a file “Resume.txt” and searching “resume” didn’t…
Isn’t that an implementation detail of whatever tool you’re using for searching for files? I seem to remember most search utilities doing that already?
Re: Git email flow vs. GitHub flow
#109Earlier quoted context omitted.
Inconvenient to who? There a many things in Linux that anyone who doesn’t use Linux full time finds majorly inconvenient, a lot of the UX around Linux is only intuitive to the 45 year old graybeard. To us 30 year old win DevOps guys Linux isn’t actually that “convenient” out of the box.
They were talking about development of the Linux kernel, not using the OS. But I also take issue with your “graybeard” comment. Unix has won out for a reason, I and many other who aren’t old hats prefer the flow of development and deployment on Linux/Unix to that of Windows.
I’m sorry, I use that as a term of endearment. The GP appeared to me to be implying that those who work on Linux prefer convenience I was just remarking that convenience doesn’t always equal ease of use for most ppl.