> -----Original Message----- > From: Philip Oakley <philipoakley@iee.email> > Sent: 27 May 2022 15:40 > To: Aman <amanmatreja@xxxxxxxxx> > Cc: Git List <git@xxxxxxxxxxxxxxx>; git-vger@xxxxxxxxxxxx > Subject: Re: About GIT Internals > > > 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. 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). > >>> 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?) Again, I don't really recognize that. You store what you want, probably with some sort of arrangement with the others on the team. The important bit is determining what will go into the release. Ie in choosing what, from everything that is stored, will be released. > >> 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. Maybe you do. If you're working with others there will probably be "permission" in some sense involved. I can store what I like locally, but then I miss out on some protection of my work, against a technical fault locally that might cause a loss of the whole repository. If there is a remote server then I am probably only allowed to store company work to the company server. A lot of this discussion seems to be more about the differences between the nature of Git and its client-server rivals. I thought the original query was about how its internals worked, which would seem to be a slightly different question. Regards, Richard. (Not old enough to remember the smell of blue prints, but old enough to know of the term)
