- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit the first line to 72 characters or less
- Reference issues and pull requests liberally after the first line
- When only changing documentation, include
[ci skip]
in the commit title - Consider starting the commit message with an applicable emoji
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:
Service | SSL | status | Response Type | Allowed methods | Allowed headers |
---|
By Golo Roden, translated from German with the help of DeepL
Every developer knows the challenge of estimating effort for development code. Very few like to do it. Why is estimating so unpopular, why is it even necessary, and what should you look for?
The question of why it's necessary to estimate effort at all is easy to answer. Knowing how long a task is expected to take is essential for planning who in a team can do what and when. Even across team boundaries, a certain amount of time planning is essential; after all, teams have to be coordinated and resources have to be procured. In addition, other departments such as marketing also have an interest in being involved in planning at an early stage.
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
#include <stdio.h> | |
#include <limits.h> | |
int main() | |
{ | |
printf("an int has %lu bytes ", sizeof(int)); | |
printf("and it can fit up to %d inside it\n", INT_MAX); | |
printf("a long long has %lu bytes ", sizeof(long long)); | |
printf("and it can fit up to %lld inside it\n\n", LLONG_MAX); |