vscode-gitlens VS Git

Quite a while ago, the GitLens+ plugin gained the Commit Graph feature--the same graph you see in GitKraken. Until then I had used Git Graph for visualizing my repositories and GitLens+ for git blame in the GUI. Since one plugin could now do both, the natural course of action was to remove the other--goodbye, Git Graph!

Btw, today I want to speak about something different, I love git and I love terminal, but sometimes I love having the info visualised appealingly and get info about the source control quickly. I work with VsCode typically, so some months ago I tried to find a solution for this editor that resolves what was said before. After googling and some testing, the result of my search was: GitLens. Now, I want to show you how it works and how it can improve your routine. So don't waste time and let's jump in it!

GitLens extension chef's kiss

for GitLens https://gitlens.amod.io/

Hi. Vs code is pretty well integrated with git. There are built in git support and a couple other plugins. For example, the most popular git plugin for vs code is git lens. It also has powerful rebase editor (i guess, it is my favorite feature), which you can enable by following this guide. I personally realy enjoing Git Graph extension, which allow you to observe your git history in pretty similar to git kraken way. It also provide navigation facilities and some other useful features.

Redder color means changes were made very recently in that area. Again you can fully customize age thresholds, locations, the color of the most recent and least recent changes, etc., from the settings.

So here are some of my favorite GitLens features that I use regularly. You can find the full list of the features here.

Phone a friend. I recommend integrating git blame into your development environment I use the Git lens plugin which shows you, directly within files in a code editor, who authored certain file changes and the PR which can be helpful for quickly getting more context regarding decisions by looking at the associated Pull Request or having the opportunity to connect directly with the committer. Pair programming can be an effective way to debug and share knowledge. Similar, to the magic of figuring out the solution to a bug in the shower or overnight there is a phenomenon called rubber ducky debugging in which just explaining the issue to someone else (even an inanimate rubber duck) can help make the solution more obvious.

If you're using VS Code, get the GitLens extension. It has an interactive rebase editor which I find very helpful (as well as heaps of other nice features).

GitLens - https://gitlens.amod.io/#features , see who did what, when and why in your IDE and also quickly see any changes you have made

Adding a 24-line comment onto every single file can be a bit annoying (although it's super unambiguous and probably makes lawyers happy). The FSF recommends this practice, although it's not required. For instance, the Git codebase mostly just mentions it in the README, COPYING, and a few other files.

Azure Devops and GitHub are just hosted solutions for git. It occurred to me that I’d never seen the repo for git but, sure enough, it’s on GitHub.

I assume you’re referring to packfiles[1], but those are (a) very much an implementation detail (they exist only to save disk space and appear basically nowhere in the git UI), and (b) not diffs—git will pack together whatever blobs its heuristics[2] think “look similar” with no regard for whether they’re actually related to each other, as long as they seem likely to gzip well together.

[1] https://git-scm.com/book/en/v2/Git-Internals-Packfiles

[2] https://github.com/git/git/blob/master/Documentation/technic...

It is important to note that all data recorded in the index is in file data units. I will describe meta information in detail later, but the storage format is exactly defined as shown in index-format.

Sounds good in theory. In practice, you get stuff like https://github.com/git/git/blob/master/cache-tree.c#L246

Interesting. https://github.com/git/git/commit/4f4be00d302bc52d0d9d5a3d4738bb525066c710

Per the post, this was a change to git itself: https://github.com/git/git/commit/4f4be00d302bc52d0d9d5a3d47...

> url = https://github.com/gitster/git

huh, I would have thought for sure they would have linked to git/git from which that repo was forked

Also, the 2.39.1 tag alleges it was created Dec 13th - I wonder why they held it so long? I would have thought maybe embargo but the actual commit says "security fix" https://github.com/git/git/commit/01443f01b7c6a3c6ef03268b64...

https://github.com/git/git isn't starred, but I guess it's because he doesn't contribute much to Git these days. But he contributes quite a lot to Subsurface.