Hello everyone. I sent out an email here last week, asking for a list
of resources, so I could better understand the workings and design of
git. I really appreciate everyone, who gave the links and their
advice.

I have been reading about GIT for some time now, and have looked at
almost all of the resources plus some others. I think I could say, I
now have a decent conceptual understanding of how GIT  works
internally.

(Also, I understood the chapter about git I read in the book I am
reading, Architecture of Open Source Applications: Volume 2, which I
didn't understand at all, the reason I started this thread). Although
there must definitely be a lot of details and subtle things I may not
understand yet (like branches are nothing but pointers to commits,
wow! btw)

Now, continuing this discussion, and talking about the implementation
and engineering side of things, I wanted to ask another question and
hence wanted some advice.

Though I may understand the internal design and high-level
implementation of GIT, I really want to know how it's implemented and
was made, which means reading the SOURCE CODE.

1. I don't know how absurd of a quest this is, please enlighten me.
2. How do I do it? Where do I start? It's such a BIG repository - and
I am not guessing it's going to be easy.
3. Would someone advise, perhaps, to have a look at an older version
of the source code? rather than the latest one, for some reason.


Again, I would really appreciate it if someone could give their
thoughts on this.

Thank you,

Regards,
Aman


On Mon, May 30, 2022 at 7:40 PM Ævar Arnfjörð Bjarmason
[off-list ref] wrote:

On Mon, May 30 2022, Konstantin Khomoutov wrote:

quoted

On Mon, May 30, 2022 at 09:49:57AM +0000, Kerry, Richard wrote:

[...]

quoted

quoted

quoted

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.

I'm not sure I get that idea.  I worked using server-based Version Control
systems from the mid 80s until about 5 years ago when the team moved from
Subversion to Git.  There was never a "curator" who controlled what went
into VC.  You did your work, developed files, and committed when you thought
it necessary.  When a build was to be done there would then be some
consideration of what from VC would go into the build. That is all still
there nowadays using a distributed system (ie Git).  Those doing Open source
work might operate a bit differently, as there is of necessity distribution
of control of what gets into a release. But those of us who are developing
proprietary software are still going through the same sort of release
process.  And that's even if there isn't actually a separate person actively
manipulating the contents of a release, it's just up to you to do what's
necessary (actually there are others involved in dividing what will be in,
but in our case they don't actively manipulate a repository).

I think, the "inversion of control" brought in by DVCS-es about a bit
differet set of things.

Re the "I'm not sure I get that idea" from Richard I think his point
stands that some of the stories we carry around about the VCS v.s. DVCS
in free/open source software was more particular to how things were done
in those online communities, and not really about the implicit
constraints of centralized VCS per-se.

Partly those two mix: It was quite common for free software projects not
to have any public VCS (usually CVS) access at all, some did, but it was
quite a hassle to set up, and not part of your "normal" workflow (as
opposed setting up a hoster git repository, which everyone uses) that
many just didn't do it.

quoted

I would say it is connected to F/OSS and the way most projects have been
hosted before the DVCS-es over: usually each project had a single repository
(say, on Sourceforge or elsewhere), and it was "truly central" in the sense
that if anyone were to decide to work on that project, they would need to
contact whoever were in charge of that project and ask them to set up
permissions allowing commits - may be not to "the trunk", but anyway the
commit access was required because in centralized VCS commits are made on the
server side.

We may have tried this in different eras, but from what I recall it was
a crapshoot whether there was any public VCS access at all. Some
projects were quite good about it, and sourceforge managed to push that
to more of them early on by making anonymous CVS access something you
could get by default.

But a lot of projects simply didn't have it at all, you'll still find
some of them today, i.e. various bits of "infrastructure" code that the
maintainers are (presumably) still manually managing with zip snapshots
and manually applied patches.

quoted

(Of course, there were projects where you could mail your patchset to a
maintainer, but maintaining such patchset was not convenient: you would either
need to host your own fully private VCS or use a tool like Quilt [1].
Also note that certain high-profile projects such as Linux and Git use mailing
lists for submission and review of patch series; this workflow coexists with
the concept of DVCS just fine.)

I'd add though that this isn't really "co-existing" with DVSC so much as
using patches on a ML as an indirect transport protocol for "git push".

I.e. if you contributed to some similar projects "back in the day" you
could expect to effectively send your patche into a black-hole until the
next release, the maintainer would apply them locally, you wouldn't be
able to pull them back down via the DVCS.

Perhaps there would be development releases, but those could be weeks or
even months apart, and a "real" release might be once every 1-2 years.

Whereas both Junio and Linus (and other linux maintainers) publish their
version of the patches they do integrate fairly quickly.

quoted

[...] it also has possible
downsides; one of a more visible is that when an original project becomes
dormant for some reason, its users might have hard time understanding which
one of competing forks to switch to, and there are cases when multiple
competing forks implement different features and bugfixes, in parallel.
One of the guys behind Subversion expressed his concerns about this back then
wgen Git was in its relative infancy [2].

 1. https://en.wikipedia.org/wiki/Quilt_(software)
 2. http://blog.red-bean.com/sussman/?p=20

It's interesting that this aspect of what proponents of centralized VCS
were fearful of when it came to DVCS turned out to be the exact
opposite:

    Notice what this user is now able to do: he wants to to crawl off
    into a cave, work for weeks on a complex feature by himself, then
    present it as a polished result to the main codebase. And this is
    exactly the sort of behavior that I think is bad for open source
    communities.

I.e. lowering the cost to publish early and often has had the effect
that people are less likely to "crawl off into a cave" and work on
something for a long time without syncing up with other parallel
development.