-
rev-parse [something]
- show the SHA of any weird git phrase
-
hash-object -w [file]
- take any file or stdin and return a blob sha
-
ls-tree (-r) [sha]
-
show the entries of a git tree in the db
In recent days (the last 12-24 hours), there have been a couple of posts on a one | |
'Marak Squires', who goes by the tag JimBastard. He stands accused of stealing code, | |
and being a general douchebag. Stealing code isn't good. Being a douchebag isn't | |
acutally illegal. However, the way that the campaign against him has been carried | |
out worries me. | |
The post to reddit that brought this issue to attention was entitled 'Code Thief at | |
Large: Marak Squires / JimBastard'. It can be found here: | |
http://www.reddit.com/r/programming/comments/ebge2/code_thief_at_large_marak_squires_jimbastard/. | |
It was a link to a github gist that can be found here: |
Consolidated lists of CSS properties that are inherited by default. | |
Taken from http://www.w3.org/TR/CSS21/propidx.html | |
-------------------------------------------------------------------- | |
One item not in the list was "text-decoration" which affects child elements. A few new properties (text-shadow) also affect child elements | |
List | |
azimuth | |
border-collapse |
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
Many users of Git are curious about the lack of delta compression at the object (blob) level when commits are first written. This efficiency is saved until the pack file is written. Loose objects are written in compressed, but non-delta format at the time of each commit.
A simple run though of a commit sequence with only the smallest change to the image (in uncompressed TIFF format to amplify the observable behavior) aids the understanding of this deferred and different approach efficiency.
Create the repo:
L1 cache reference ......................... 0.5 ns
Branch mispredict ............................ 5 ns
L2 cache reference ........................... 7 ns
Mutex lock/unlock ........................... 25 ns
Main memory reference ...................... 100 ns
Compress 1K bytes with Zippy ............. 3,000 ns = 3 µs
Send 2K bytes over 1 Gbps network ....... 20,000 ns = 20 µs
SSD random read ........................ 150,000 ns = 150 µs
Read 1 MB sequentially from memory ..... 250,000 ns = 250 µs
Locate the section for your github remote in the .git/config
file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
People
:bowtie: |
😄 :smile: |
😆 :laughing: |
---|---|---|
😊 :blush: |
😃 :smiley: |
:relaxed: |
😏 :smirk: |
😍 :heart_eyes: |
😘 :kissing_heart: |
😚 :kissing_closed_eyes: |
😳 :flushed: |
😌 :relieved: |
😆 :satisfied: |
😁 :grin: |
😉 :wink: |
😜 :stuck_out_tongue_winking_eye: |
😝 :stuck_out_tongue_closed_eyes: |
😀 :grinning: |
😗 :kissing: |
😙 :kissing_smiling_eyes: |
😛 :stuck_out_tongue: |