Re: About GIT Internals

>
> Hey, thank you again.
>
> I am finding this mailing list format of talking a bit confusing, sorry.
>

>
> I found out the mailing list archive (so confusing)– and saw these 
> personal replies don’t get added in the thread. I would appreciate if 
> you give some advice, thank you
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for 
> Windows
>
> From: Philip Oakley <mailto:philipoakley@iee.email>
> Sent: 27 May 2022 08:10 PM
> To: Aman <mailto:amanmatreja@gmail.com>
> Cc: Git List <mailto:git@vger.kernel.org>; git-vger@eldondev.com
> Subject: Re: About GIT Internals
>
> Hi Aman,
>
> We try to keep all the cc's so every one can gain from the learning!
>
> comments in-line.
>
> On 26/05/2022 15:17, Aman wrote:
>
> > Hey Phillip.
>
> >
>
> > Thanks a lot for your email, and for sharing the book! This is great.
>
> That was Eldon, thank you..
>
> (https://lore.kernel.org/git/Yo68+kjAeP6tnduW@invalid/)
>
> There is also the Git Magic 'book' from Stanford, with Ch8 covering the
>
> internals http://www-cs-students.stanford.edu/~blynn/gitmagic/ch08.html
>
> >
>
> > Just a  follow up questions- if you don't mind:
>
> >
>
> > 1. I haven't had the experience of working with other (perhaps even
>
> > older) version control systems, like subversion. So when refering to
>
> > the "control" aspect,
>
> The "control" aspect was from whoever was the 'manager' that limited
>
> access to the version system (i.e. acting like a museum curator), and
>
> deciding if your masterpiece was worthy of inclusion as a significant
>
> example of your craft, whether that was an engineering drawing or some
>
> software code.
>
> >   you mean because with hashes we can verify
>
> If you have a look at
>
> https://www.makeuk.org/insights/blogs/how-to-read-engineering-drawings-a-simple-guide 
>
>
> and the part about the Title Block has a drawing (DWG) number
>
> (EEF-001-AM) that is used to reference it and, while it feels nice, the
>
> reference is rather arbitrary, (could someone else use that number?
>
> what's the next in the sequence? what happens when we reach EEF-999-AM?
>
> etc.).
>
> So the computer hash (40 digits of 0-9a-f !) solves all those problems,
>
> it is unique (>40 card shuffle level), depends only on the content,
>
> computers like it. Yay.
>
> (Computers are great at perfect replication, so cost of manufacture
>
> tends to zero! Cost of design wanders in the other direction;-)
>
> > the
>
> > integrity of the files (like code) in git - there is no need for
>
> > having a central authority to guarantee that's it's the right content
>
> > files (which is great)?
>
> And it means managers no longer worry about _your_ working copy -
>
> computers have digital storage space to spare. That wasn't the case when
>
> it was on paper, and we didn't have photocopies - have a look at 'blue
>
> prints' https://en.wikipedia.org/wiki/Blueprint (see the invention
>
> date!, I still remember the smell from the late 1970s)
>
> >
>
> > On Thu, May 26, 2022 at 2:17 PM Philip Oakley 
> <philipoakley@iee.email> wrote:
>
> >> On 26/05/2022 00:34, git-vger@eldondev.com wrote:
>
> >>> Hi Aman, responses inline below.
>
> >>>
>
> >>> On Wed, May 25, 2022 at 09:40:42PM +0530, Aman wrote:
>
> >>>> Could someone please assist - in sharing some resources - which I
>
> >>>> could go through, to better understand GIT software internals.
>
> >>> There is an excellent free book at https://git-scm.com/book/en/v2 .
>
> >>>
>
> >>> Chapter 10 is about git internals. It is important to realize that,
>
> >>> unlike many other version control systems, git works effectively on
>
> >>> files locally on your computer, without any server or other shared
>
> >>> resources to manage. Also, one good way to learn may be to form a
>
> >>> question that you want to answer first. "How do I ...." or "what 
> happens
>
> >>> when I ...". Since git works locally, it is possible to create a git
>
> >>> repo, look at the files contained in the .git directory, take action
>
> >>> with git, and then look at the files again.
>
> >>>
>
> >>>
>
> >> Another Git feature, compared to older version control systems, is that
>
> >> it flips the 'control' aspect on its head. (who controls what you can
>
> >> store?)
>
> >>
>
> >> It does this by using the hash (sha1, or sha256) values as a way of
>
> >> users _checking_ that they have the right copy of a file or commit,
>
> >> rather than needing special permissions to access (write/read) some
>
> >> alleged 'master' copy (in the sense of a unique artefact) of the
>
> >> particular version. Maintainers now check and authorise particular
>
> >> versions much more easily.
>
> >>
>
> >> Hence Git _Distributes Control_ - you no longer need permission to keep
>
> >> versioned copies of your work. This was, in my mind, a core element of
>
> >> its success.
>
> >>
>
> >> There is other stuff about how Git splits the (file) content from it's
>
> >> meta-data, so if say 10 files contain the same licence text, then it
>
> >> only hold one copy of that text, with its own unique hash. Then has a
>
> >> hierarchy (pyramid) of hashes of the meta-data to build up a whole
>
> >> project's hash (the top level 'tree'), and the same hierarchy technique
>
> >> is repeated for the project's history of commits.
>
> >>
>
> >> If you have a copy of the repository with the latest (same) hash then
>
> >> you have a perfect copy, indistinguishable to the 'original'! Older
>
> >> versioning systems did not have those guarantees, many were derived 
> from
>
> >> systems for versioning engineering and architectural drawings such as
>
> >> those that were used for the RMS Titanic or Empire State Building.
>
> >>
>
> >> Philip
>
> >>
>
> >> PS it's worth checking out the distinction between having hash (a magic
>
> >> id) of some text, and encrypting (a magic translation of) some text.
>
> >>
>
> >>
>