The more I discover git, the more I learn we can do everything with it!

Notes can be attached to git objects. We can then store plain text in these. So commente, review and so on. I added other posts relatée to git notes in the shaarli.

Forks are copy of the original repository. As such, leaked credentials remains in the forks.

A deleted repository still has the commit from the original repository and it can access it. Demo on youtube

Example:

They immediately deleted the repository, but since it had been forked, I could still access the commit containing the sensitive data via a fork

Also related to private repositories:

We demonstrate how organizations open-source new tools while maintaining private internal forks, and then show how someone could access commit data from the private internal version via the public one.

How to access the data? By direct access to the commit.

If you know the commit hash you can directly access data that is not intended for you.

AND

Commit hashes can be brute forced through GitHub’s UI, particularly because the git protocol permits the use of short SHA-1 values when referencing a commit.

because there are 65.536 minimal values, and 16.777.216 is a more realistic approach (6 characters per commit).

Also, "deleting a repository or fork does not mean your commit data is actually deleted."

The flaw also exists in other version control system products.

An extension of git to work with stacked PRs.

Great insights :)

Some commits are misattributed. This is annoying as the proof of work is one of the most important reward in open source.

Maybe 1% are?

What is a git reference?

A git recent pretty-prints the last poked branches:

[alias]
    recent = ! git branch --sort=-committerdate --format=\"%(committerdate:relative)%09%(refname:short)\" | head -10

and more

A git bingo: did you hear all of these?

Git can be extended in many ways. The author of b4 created a cli tool to simplify the patches communicated by email for the linux kernel developers.

Notes stow metadata about anything tracked by git—any object: commits, blobs, and trees.

The git project itself offers an example of git notes in the wild. They link each commit to its discussion on their mailing list.

Other folks are using notes for things like:

• Tracking time spent per commit or branch
• Adding review and testing information to git log
• And even fully distributed code review

Review notes are used by Gerrit (Wikimedia) and many google projects. For example:

commit d1d17908d2a97f057887a4afbd99f6c40be56849
Author: User <user@example.com>
Date:   Sun Mar 27 18:10:51 2022 +0200

    Change the thing

Notes (review):
    Verified+1: SonarQube Bot
    Verified+2: jenkins-bot
    Code-Review+2: Reviewer Human <reviewerhuman@wikimedia.org>
    Submitted-by: jenkins-bot
    Submitted-at: Tue, 14 Jun 2022 21:59:58 +0000
    Reviewed-on: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/774005
    Project: mediawiki/core
    Branch: refs/heads/master

There is also an extension from Google to git notes dedicated to code review: https://github.com/google/git-appraise. Request review, comment and review and merge are included.

Its authors have declared it a “fully distributed code review”—independent of GitHub, GitLab, or any other code forge.

Git notes are however a pain to use. Mhmhmhm #idea #project on top of the git note commands?

For commits, you can make viewing and adding notes easier using fancy options in your gitconfig3. But for storing notes about blobs or trees? Forget it. You’d need to be comfortable rooting around in git’s plumbing first.

Much of the value of git repos ends up locked into forges, like GitHub. Git notes are a path toward an alternative and it could make it possible to distribute the history of an entire project.

Critics of Git, if someone had to improve from its weaknesses.

sha1 was a bad choice back then. The moral here is "treat your identifiers as opaque strings" along with "sometimes a sha1: prefix doesn't hurt anyone"

Email and names in every commits:

I guess when you read lkml, the notion of spam isn't too worrying, but putting names and emails into every commit means any time someone changes name or email, they might as well be a whole different person to the repo.
Sure enough, when you store names in the files, you have to rewrite history when someone changes email address, but in another world, you'd use a UUID and a file called .gitauthors that maps one to the other

There are two different mechanisms for almost every feature.

git forces you to make a choice. use merge and get a noisy, but representative history. use rebases and lose some of the work, but the log is a lot easier to navigate.
we could also have a version of git log that didn't make merges look like shit, but that's another problem altogether.

the unix philosophy is about building toolkits, not applications

in other words: have you ever accidentally committed inside a rebase? or accidentally committed a conflict? tough shit, fucko.
git commands are named after implementation, not use, and there's absolutely no excuse for it
flat files kind of suck if your state gets corrupted.

git is made from papercuts

there's bits where you can't check in an empty directory, or how you can set files to ignore but not files to include.

#project #idea make it better