Blinking Commits(blog.annharter.com) |
Blinking Commits(blog.annharter.com) |
Unfortunately Sublime wasn't happy with me trying to type it through the Mac Unicode Hex input, but I was able to copy-paste it in, and I was also able to enter it directly in other programs, like GitHub desktop.
git commit -F <(curl https://raw.githubusercontent.com/thiderman/doge/master/doge/static/doge.txt) # [0]
Oh god do I feel bad about this. What have I done? git commit --allow-empty -F <(curl https://raw.githubusercontent.com/thiderman/doge/master/doge/static/doge.txt)But you can make your text black with a black background. Or re-order lines, which I suspect to be "fun" for git logs.
https://iterm2.com/images.html
Edit: even animated gifs
It could be useful for highlighting risky commits in red or other visual markers.
Would play merry hell with almost every other way of viewing commits though :D
>It could be useful for highlighting risky commits in red or other visual markers.
Yeah... that is really not a good idea. You are not supposed to take this blog post seriously.
Why not just agree on some terminology like CRITICAL/MINOR/SECURITY, which a visual interface can then highlight?
SECURITY: Fix XSS in spline reticulation
If it detects "SECURITY" it adds a red background, etc. Anyone viewing the raw text version of the commit messages will still get the message without having to see a bunch of gibberish.And you were not supposed to take my comment seriously... I thought I made that obvious with the last sentence but oh well.
Actually it has something to do with git. Git should strip or escape the user input before displaying. XSS and SQL Injections are the same kind of issue -> do not trust the user input and escape the input before interaction with it happens.
Git commit messages are used for lots of different things, but at the end of the day it's just another piece of data included in a hash in a content-addressable file system.
If you're doing something with that tool where including formatting like this would be considered a vulnerability, it's on you to take care of that. It's exactly the same with any other bug or exploit in your codebase: it's not git's fault that you committed it.
Finding someone who can write very technically while also being funny and charismatic is pretty rare (We computer types aren't always the biggest hits at parties). I also really appreciate his "last time on" opening paragraphs... it gives some context to the blog post and where's coming from in his headspace. Neat.
At first, I was surprised to find I falsely assumed she was male in spite of evidence to the contrary, and was going to thank you for making me more aware of my own oversight. Upon review, however, I made the correct assumption that it was non-gendered. I'll forego the inciting comment, and corresponding cultural political flamewar over my use of a singular default male pronoun. If you down-voted me, please understand that doing so is alienating and a disservice to conversations. We should not punish commenters for failing to conform to our own personal cultural norms. This is consistent with the spirit of your comment; engineers need not conform to external expectations of a masculine identity.
[1] Her handles at the bottom are neither pronouns, nor in the blog post, and were inconsequential to me given my present lack of motive for reaching out to the author.
Works for OS X apparently.
I think this is quite harmful, especially the character movement ansi escapes could be used for nefarious purposes.
[0] https://news.ycombinator.com/item?id=10035008
[1] https://github.com/minimaxir/big-list-of-naughty-strings/blo...
A fun exercise is to write a function that overwrites string A with string B, starting at index N. It's hard enough with unicode, but ANSI escapes make it more fun.
[0]: https://github.com/tillberg/ansi-log (Go logging library with support for ANSI colors and interleaving multiple writers)
Like what?
- Rewrite the commit hash in git log with character movement
Actually I don't know if it's a practical attack in any way, could cause some confusion.
Off by default; enable and blink like its 1989.
[5mFoo[0m...Lord, when did I get so old? :/
Anyway, they default to "linux" for more than a decade.
Although I do wonder what havoc you could wreak on hosted git services with cunning sequences of control characters. Smacks of injection.
Let's not go crazy now.
[0] http://webpages.charter.net/danrollins/techhelp/0087.HTM
[1] http://sourceforge.net/p/linux-fbdev/mailman/message/7849329...
https://en.wikipedia.org/wiki/ANSI_escape_code
It's definitely a terminal thing. The "bug" in git is that it doesn't strip out the control characters or reject the commit if the commit message contains non-text data.
The ideal solution is to sanitize all data before displaying it
on your terminal, however without a custom terminal application
or data filter, you can't guarantee that every tool you use on
the command-line is going to strip escape sequences. The
responsibility should rest on the actual terminal emulator; any
features that allow file or command-line access should be
disabled by default and more attention should be paid to new
features that implement any use of escape sequences. [0]
Are you cloning untrusted repositories to your computer and running git log blindly?I mean, it would be super nice for your terminal emulator to just automagically filter out escape sequences when you, the user, do not want them and to allow them for programs that you do. a whitelist would work but would be super annoying to actually verify as so many programs output things from so many different inputs. it seems like programs themselves should decide if they need to output arbitrary data and, in cases where they don't, like git, they can filter it.
I'm not sure why you think he/his pronouns are nongendered. The nongendered pronouns in English are they/them.
> I think I only get ten [downvotes] a day, so I save them for the really annoying comments.
10 downvotes a day? Please reconsider your behavior. You are almost certainly unnecessarily alienating commenters, and in this case, misguidedly so.
> I'm not sure why you think he/his pronouns are nongendered.
When I said "it was non-gendered," I was referring to the blog post, which meant your original comment, "The author uses female pronouns," is factually incorrect.
> The nongendered pronouns in English are they/them.
I'm aware, and intimated as much: "I'll forego [discussing] my use of a singular default male pronoun". Yes, they/them is non-gendered, but it is also plural, making it grammatically historically incorrect. However, despite the informality of my comment, given the extreme propensity of the "generic he" to be controversialized, especially in technology and the internet, and the movement away from it during my lifetime, I'll placate to avoid the negative insinuations.
Educating yourself on the context of the matter would go a long way to ameliorate your sanctimonious attitude, and hopefully disincline you to feel the need to controversialize, divert and detract from conversations in the future.
he/his and they/them both have well-established non-gender-specific meanings in the more recent (social) meaning of "gender" (prior to that fairly recent linguistic evolution, words had gender and people had sex -- while its useful to have a term for the distinct feature of people referred to by "gender" as distinct from "sex", its a very different thing than grammatical "gender", and grammatical gender doesn't have a 1:1 mapping to linguistic constructs whose semantics refer to social gender), though he/his also has a gender-specific meaning (and there is considerable potential for ambiguity between the gender-neutral and gender-specific senses of he/his.)
This reasoning turns me off from types who have it.
It's not like they use emoticons everywhere -- and if having one is the big distraction one can complaint about, then their repo is in excellent shape.
It's all going to depend on the team; it would be a mistake to conflate seriousness with competence.
And all of their "serious" work will amount to absolutely nothing in just 100 years (that's it if they're lucky: for most their work wont matter at all in 10 or 20 years, their companies shuw down, or bought and dismantled, their startup dreams shattered etc.).
(A lot of them will even regret working so hard and giving importance to the BS they gave importance to after they retire).
Just to put some mature perspective on being playful.
Still, the OC was factually incorrect and this entire topic is diverting and as you've now contributed to with your sanctimonious desire to prove me wrong, controversialized and alienating here on HN.