git gc, loose and packed git objects

Intro:
Recently during lunch, a bunch of us started discussing git internals. One popular point of contention that came-up was how git stores the incremental changes internally?

The Question:

Does the .git subdirectory contain:
- compressed diffs that apply on the original version of each file?
    OR
- compressed copy of each version of each modified file?

The Answer:
Different blogs appeared to claim differently [1] [2], and we were too lazy to go look-up the definitive source - the source-code of git.

Warning: The following video is processed in a facility that also processes nuts.

 Contains traces of the 60's Batman TV show.

The Conclusion:

Another mystery solved. git gc to the rescue...

References:
[1] https://codewords.recurse.com/issues/two/git-from-the-inside-out
[2] https://schacon.github.io/gitbook/1_the_git_object_model.html
[3] https://schacon.github.io/gitbook/7_how_git_stores_objects.html
[4] https://schacon.github.io/gitbook/7_the_packfile.html

Meanwhile... having solved the riddle,
the caped-crusader and the wonder-boy went to Gotham city's garbage collection facility
in the Bat-mobile to foil whatever plan the Riddler's hatching...

Git prevision

Need to quickly check a previous version of a specific file?...
Do not want to switch the entire repository to an older commit and back?...

A combination of git aliases/awk/shell-functions to the rescue

Here is a quick and intuitive way to checkout a older version of a single file in git.

Basically the command does a git log on the specified file and picks the appropriate commit-id in the history of the file and then runs git checkout to the commit-id for the specified file.

Essentially, all that one would manually do in this situation, wrapped-up in one beautiful, efficient git-alias - git-prevision

Liked git-prevision? Help others discover git-prevision.
Upvote git-prevision on StackOverflow.

[patch] [resend] Preparing a modified patch

In case of any collaborated project (eg. linux-kernel), often after submitting a patch for review,  we often receive several comments and need to make appropriate changes and generate a new "version2" of the patch containing the changes. If we are using Git for revision control, then the entire process becomes a snap.

How to prepare a modified patch for resend in 5 easy steps:

STEP1.
git rebase -i <commit-id-just-before-our-changes>

STEP2.
As discussed in the review, make the new changes to the source-files.

STEP3.
git add <modified-filenames>

STEP4.
git commit --amend
(shows editor with original commit-msg)
Edit the commit-msg (or leave as-is) and quit.
New commit is generated in the place of old commit.

STEP5.
git format-patch HEAD~1
DONE!! New patch version2 is ready for review now. :-)

If we do a diff between the PREV and NEW patch, we can see :

+ Changes made after review.

+ Time-Stamp change.

+ Hash change.