The shortest pull request ever
github.com
The shortest pull request ever
1–10 of 55 posts
Re: The shortest pull request ever
#2> If we drop those markers (1110 and 10 in front of bytes) and keep the remaining bits we're left with 1111111011111111, which evaluates to 65279, which is in hexadecimal 0xfeff. Yes, you recognize it, it's a BOM. Because yes a BOM is just a ZERO WIDTH NO-BREAK SPACE, isn't it beautiful?
Byte Order Marks have stolen hours and days of my life. Anyone suffering the pain of developing on a windows box can relate. Windows puts BOMs by default in the front of every file. Thus windows programs silently ignore it, but then linux machines run the program and choke on the BOM. You have to specifically ask the editor if the BOM is even there, it doesn't show up in the editor by default. I have specific lines in my .vimrc[1] that prevent BOMs from ruining my day/week, but they still pop up often. I often joke there will be a byte order mark on my tombstone, along with avahi daemon.
1: https://git.sr.ht/~djha-skin/dotfiles/tree/main/item/dot-con...
Re: The shortest pull request ever
#3I mean, it's the shortest _possible_ pull request (since I don't think you can make a git diff of zero bytes, barring some weird quirk), but also probably has the highest PR description : PR diff length ratio of any PR I've seen.
Re: The shortest pull request ever
#4I mean, it's the shortest _possible_ pull request (since I don't think you can make a git diff of zero bytes, barring some weird quirk), but also probably has the highest PR description : PR diff length ratio of any PR I've seen.
I think file mode changes (eg 0644 -> 0755 to fix a script not running) could be smaller
Re: The shortest pull request ever
#5I mean, it's the shortest _possible_ pull request (since I don't think you can make a git diff of zero bytes, barring some weird quirk), but also probably has the highest PR description : PR diff length ratio of any PR I've seen.
Depends on whether you consider `git commit --allow-empty` a weird quirk ... I guess it would be reasonable to do so ;).
Re: The shortest pull request ever
#6I mean, it's the shortest _possible_ pull request (since I don't think you can make a git diff of zero bytes, barring some weird quirk), but also probably has the highest PR description : PR diff length ratio of any PR I've seen.
`git commit --allow-empty -m 'empty commit'` will do.
Re: The shortest pull request ever
#7Over the years I've submitted a decent number of pull requests just removing execute bits from files that shouldn't be executable.
They always end up +0-0 - see:
Re: The shortest pull request ever
#8I mean, it's the shortest _possible_ pull request (since I don't think you can make a git diff of zero bytes, barring some weird quirk), but also probably has the highest PR description : PR diff length ratio of any PR I've seen.
Depends on whether you consider `git commit --allow-empty` a weird quirk ... I guess it would be reasonable to do so ;).
What's the purpose of this? I can think of ways to use/abuse it, but there has to be a specific reason that it was added as a feature to git.
Re: The shortest pull request ever
#9> If we drop those markers (1110 and 10 in front of bytes) and keep the remaining bits we're left with 1111111011111111, which evaluates to 65279, which is in hexadecimal 0xfeff. Yes, you recognize it, it's a BOM. Because yes a BOM is just a ZERO WIDTH NO-BREAK SPACE, isn't it beautiful? Byte Order Marks have stolen hours and days of my life. Anyone suffering the pain of developing on a windows box can relate. Window…
> Byte Order Marks have stolen hours and days of my life.
Me too, to some degree. I have discovered them in a Ruby code base at work, in the middle of a line of code (copy pasted), where the Ruby interpreter thinks they are undeclared identifiers. When the code runs, it throws an exception every time that complains of “Undeclared identifier `‘”.
The dad-joke of it is that “You gotta sweep for BOMs before they blow up your code.”
Re: The shortest pull request ever
#10Earlier quoted context omitted.
Depends on whether you consider `git commit --allow-empty` a weird quirk ... I guess it would be reasonable to do so ;).
What's the purpose of this? I can think of ways to use/abuse it, but there has to be a specific reason that it was added as a feature to git.
I see `--allow-empty` in git tutorials all the time, to demonstrate the concept of a commit. I'm not sure when you'd reach for it in a real repo though