#git

#humorinformatykow #git

Pierwsze README #git napisane przez #linustorvalds w 2005. W następnym commicie który dotyka tego pliku obok zmienił .dircache/index -> .git/index.

https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23ca2e25604af290#diff-2b7814d3fca2e99e56c51b6ff2aa313ea6e9da6424804240aa8ad891fdfe0900

GIT - the stupid content tracker

"git" can mean anything, depending on your mood.

- random three-letter combination that is pronounceable, and not
actually used by any common UNIX command. **The fact that it is a
mispronounciation of "get" may or may not be relevant.**
- stupid. contemptible and despicable. simple. Take your pick from the
dictionary of slang.
- "global information tracker": you're in a good mood, and it actually
works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks

This is a stupid (but extremely fast) directory content manager. It
doesn't do a whole lot, but what it does do is track directory
contents efficiently.

There are two object abstractions: the "object database", and the
"current directory cache".

The Object Database (SHA1_FILE_DIRECTORY)

The object database is literally just a content-addressable collection
of objects. All objects are named by their content, which is
approximated by the SHA1 hash of the object itself. Objects may refer
to other objects (by referencing their SHA1 hash), and so you can build
up a hierarchy of objects.

There are several kinds of objects in the content-addressable collection
database. They are all in deflated with zlib, and start off with a tag
of their type, and size information about the data. The SHA1 hash is
always the hash of the compressed object, not the original one.

In particular, the consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
forms a sequence of + + <ascii decimal
size> + <byte\\0> + .

BLOB: A "blob" object is nothing but a binary blob of data, and doesn't
refer to anything else. There is no signature or any other verification
of the data, so while the object is consistent (it is indexed by its
sha1 hash, so the data itself is certainly correct), it has absolutely
no other attributes. No name associations, no permissions. It is
purely a blob of data (ie normally "file contents").

TREE: The next hierarchical object type is the "tree" object. A tree
object is a list of permission/name/blob data, sorted by name. In other
words the tree object is uniquely determined by the set contents, and so
two separate but identical trees will always share the exact same
object.

Again, a "tree" object is just a pure data abstraction: it has no
history, no signatures, no verification of validity, except that the
contents are again protected by the hash itself. So you can trust the
contents of a tree, the same way you can trust the contents of a blob,
but you don't know where those contents came from.

Side note on trees: since a "tree" object is a sorted list of
"filename+content", you can create a diff between two trees without
actually having to unpack two trees. Just ignore all common parts, and
your diff will look right. In other words, you can effectively (and
efficiently) tell the difference between any two random trees by O(n)
where "n" is the size of the difference, rather than the size of the
tree.

Side note 2 on trees: since the name of a "blob" depends entirely and
exclusively on its contents (ie there are no names or permissions
involved), you can see trivial renames or permission changes by noticing
that the blob stayed the same. However, renames with data changes need
a smarter "diff" implementation.

CHANGESET: The "changeset" object is an object that introduces the
notion of history into the picture. In contrast to the other objects,
it doesn't just describe the physical state of a tree, it describes how
we got there, and why.

A "changeset" is defined by the tree-object that it results in, the
parent changesets (zero, one or more) that led up to that point, and a
comment on what happened. Again, a changeset is not trusted per se:
the contents are well-defined and "safe" due to the cryptographically
strong signatures at all levels, but there is no reason to believe that
the tree is "good" or that the merge information makes sense. The
parents do not have to actually have any relationship with the result,
for example.

Note on changesets: unlike real SCM's, changesets do not contain rename
information or file mode chane information. All of that is implicit in
the trees involved (the result tree, and the result trees of the
parents), and describing that makes no sense in this idiotic file
manager.

TRUST: The notion of "trust" is really outside the scope of "git", but
it's worth noting a few things. First off, since everything is hashed
with SHA1, you can trust that an object is intact and has not been
messed with by external sources. So the name of an object uniquely
identifies a known state - just not a state that you may want to trust.

Furthermore, since the SHA1 signature of a changeset refers to the
SHA1 signatures of the tree it is associated with and the signatures
of the parent, a single named changeset specifies uniquely a whole
set of history, with full contents. You can't later fake any step of
the way once you have the name of a changeset.

So to introduce some real trust in the system, the only thing you need
to do is to digitally sign just one special note, which includes the
name of a top-level changeset. Your digital signature shows others that
you trust that changeset, and the immutability of the history of
changesets tells others that they can trust the whole history.

In other words, you can easily validate a whole archive by just sending
out a single email that tells the people the name (SHA1 hash) of the top
changeset, and digitally sign that email using something like GPG/PGP.

In particular, you can also have a separate archive of "trust points" or
tags, which document your (and other peoples) trust. You may, of
course, archive these "certificates of trust" using "git" itself, but
it's not something "git" does for you.

Another way of saying the same thing: "git" itself only handles content
integrity, the trust has to come from outside.

Current Directory Cache (".dircache/index")

The "current directory cache" is a simple binary file, which contains an
efficient representation of a virtual directory content at some random
time. It does so by a simple array that associates a set of names,
dates, permissions and content (aka "blob") objects together. The cache
is always kept ordered by name, and names are unique at any point in
time, but the cache has no long-term meaning, and can be partially
updated at any time.

In particular, the "current directory cache" certainly does not need to
be consistent with the current directory contents, but it has two very
important attributes:

(a) it can re-generate the full state it caches (not just the directory
structure: through the "blob" object it can regenerate the data too)

As a special case, there is a clear and unambiguous one-way mapping
from a current directory cache to a "tree object", which can be
efficiently created from just the current directory cache without
actually looking at any other data. So a directory cache at any
one time uniquely specifies one and only one "tree" object (but
has additional data to make it easy to match up that tree object
with what has happened in the directory)


and

(b) it has efficient methods for finding inconsistencies between that
cached state ("tree object waiting to be instantiated") and the
current state.

Those are the two ONLY things that the directory cache does. It's a
cache, and the normal operation is to re-generate it completely from a
known tree object, or update/compare it with a live tree that is being
developed. If you blow the directory cache away entirely, you haven't
lost any information as long as you have the name of the tree that it
described.

(But directory caches can also have real information in them: in
particular, they can have the representation of an intermediate tree
that has not yet been instantiated. So they do have meaning and usage
outside of caching - in one sense you can think of the current directory
cache as being the "work in progress" towards a tree commit).

#programowanie

Zwykle udostępniam tu artykuły, które publikuję na swoim blogu. Tym razem mam jednak do pokazania coś większego 🎉

294 dni. Tyle minęło od napisania pierwszego zdania do postawienia ostatniej kropki mojego najnowszego e-booka. „Kolejna książka o Gicie” w końcu ujrzała światło dzienne i jestem ogromnie dumny z produktu, który mogę Ci dziś zaprezentować!

„Kolejna książka o Gicie” to ponad 180 stron konkretnej i praktycznej wiedzy. E-book przeprowadzi Cię krok po kroku od podstaw po bardziej zaawansowane treści. Nie jest to jedynie teoretyczny opis działania Gita, ale opisałem również praktyczne wskazówki i rekomendacje, które pomagają pracować z nim lepiej i efektywniej.

Oprócz treści teoretycznej w e-booku znajdziesz sporo ćwiczeń praktycznych pozwalających na przetrenowanie zdobytej wiedzy i wykorzystanie Gita w skryptach czy automatyzacjach.

W premierowym artykule znajdziesz szczegółowe informacje dotyczące zawartości e-booka :point_down:

https://devszczepaniak.pl/kolejna-ksiazka-o-gicie-premiera/

#git

#ebook

#programowanie

#informatyka

#programista15k

#frontend

#naukaprogramowania

#backend

Jakiś czas temu, analizując dokumentację Gita, natknąłem się na polecenie git notes. Myślałem, że znam Gita całkiem dobrze, ale to było dla mnie coś nowego. W najnowszym artykule wyjaśniam, czym są git notes i analizuję możliwości, jakie daje ta funkcja. Dowiesz się również jakie problemy widzę w

Po instalacji Gita zwykle konfigurujemy adres e-mail, nazwę użytkownika czy wykorzystywany edytor. Często po pierwszej konfiguracji Gita rzadko w niej coś zmieniam — a szkoda. Git daje całkiem sporo możliwości, które mogą usprawnić codzienną pracę. W artykule pokazuję kilka mniej oczywistych

Duże pull requesty to problem, który łatwo rozwiązać dzieląc je na mniejsze. Pojawia się wtedy inny problem. Jeśli zmiany z jednego pull requesta są wymagane w kolejnym, potrzebujemy poczekać na code review... lub skorzystać z podejścia opisanego w podlinkowanym artykule. Założeniem

#git #linustorvalds #programowanie #github

Two decades of Git: A conversation with creator Linus Torvalds
https://youtu.be/sCr_gb8rdEI

Trochę późno na pierwszy w życiu pull request, ale jest #git (´･ᴗ･ ` )
W końcu opanowałem o co kaman w tym ambarasie, choć nigdy nie chciało mi się wrzucać jakichkolwiek poprawek.

W sumie hak żeby być kontrybutorem linuxa na githubie.

https://github.com/torvalds/linux/pull/832
>Well, the rules for getting a GitHub PR merged by @torvalds are here, so it is not impossible: #17 (comment). Just very uncommon. It only happened 10 times.
I wyjaśnienie: https://github.com/torvalds/linux/pull/832#issuecomment-2193883290
>No Linux PRs have ever been merged via GitHub. What happened here is that a random person submitted a branch that was already sent to Linus via a mailing list PR.
>
>This is the real (non-GitHub) PR. The timestamp is Sun, 31 Mar 2024 10:27:11 UTC. @ammarfaizi2 then opened this GitHub PR at 12:37 UTC, a couple hours later, using the exact same commit hash, even though he is neither the commit author nor the person making the PR. Then when Linus merged this (again, not involving GitHub at all) into mainline, and this mirror was updated to include the merge commit, GitHub marked the PR as merged since the commit that this PR was attempting to merge was, in fact, merged (this is a GitHub feature that works as long as the commit hash is identical, and included in a subsequent merge commit). At no point was GitHub involved in the process with the actual kernel community, and as far as I can tell @ammarfaizi2 is just a random who had nothing to do with the commit, nor the real PR, or anything else.
>
>Anyone can do this by running ahead of Linus on any non-GitHub kernel pull request and opening a PR here. It's just a stupid trick to make it look like Linus merged your PR via GitHub, even though that never actually was the case.
>
>You can submit Linux kernel changes to upstream maintainers from GitHub-hosted branches, I've done so myself. But it's via mail PR, and GitHub in that case is just treated as an arbitrary Git hosting site. The GitHub web interface PRs are never used.
#linux #github #git

Henlo frens

Pod ostatnim postem pojawiły się komentarze pytające o link to kodu aplikacji. Także pod spodem podsyłam link do #git . Mam jeszcze plik apk i pakiet pod linuxa ale muszę sprawdzić czy działają. Ze zmian wprowadziłem tylko ładowanie miniaturek pięciu pierwszych przedmiotów przedmiotów. Dlaczego pięciu pierwszych? Bo #olx stosuje leazy loading i bo zaciągnięciu strony wartości scr tagu #html są dostępne tylko dla pierwszych pięciu przedmiotów. Da się to obejć zaciągając strone z linku prowadzącego bezpośrednio do danego przedmiotu i scrapując ją. Zawiera ona src do wszyskich zdjęć jakie sprzedający wstawił. Jednak uznałem że bombardowanie olxa setkami zapytań nie jest dobrym pomysłem.

https://gitlab.com/AdamPWr/olxviever

#programowanie #flutter #diy #android #ios #apustaja

Wyobraź sobie projekt na Github, który jest prowadzony przez pięć grup, i każda chce zaszkodzić pozostałym grupom, i ma własne sprzeczne pomysły.
Jak prowadzić sensownie taki projekt?

Tak, mówię o sejmie.

A pytanie na serio. Da się coś z tym fantem zrobić?

#github #git #webdev #programowanie

#git #programowanie

Twitter jako git

https://github.com/diracdeltas/tweets

Alternatywa dla Gitlaba bazująca na Gitea

https://codeberg.org/

Dzisiaj jest ostatni dzień, by zapisać się na nieodpłatny kurs CS50 HarvardX. W programie:

HTML, CSS
Git
Python
Django
SQL, Models, and Migrations
JavaScript
User Interfaces
Testing, CI/CD
Scalability and Security

Zapisy: https://polishwords.com.pl/go/-43l

#dlaprogramistow #programowanie #naukaprogramowania #programujzwykopem #javascript #git #html #css #python #django #userexperience

Jak nie chcesz przegapiać takich okazji, zapisz się na newsletter: https://polishwords.com.pl/blog/newsletter-dla-programistow/

PHP po latach rezygnuje z hostowanej przez siebie infrastruktury GIT. Mirror, który posiadali na GitHubie staje się teraz głównym źródłem kodu.

Wszystko w związku z...dwoma commitami wprowadzającymi backdoor do kodu PHP-a. Commitami, które pojawiły się prawdopodobnie przez nieautoryzowany dostęp do starego repozytorium. "Nieautoryzowana" zmiana pozwalała na wykonanie arbitrary code injection (w tym wypadku wykonanie kodu PHP) z nagłówka HTTP o osobliwej nazwie "HTTP_USER_AGENTT".

[news] https://news-web.php.net/php.internals/113838
[commit-1] https://github.com/php/php-src/commit/c730aa26bd52829a49f2ad284b181b7e82a68d7d
[commit-2] https://github.com/php/php-src/commit/2b0f239b211c7544ebc7a4cd2c977a5b7a11ed8a

Opensourcowa gra do nauki Gita - Oh My Git

https://ohmygit.org/