On Wed, Dec 22, 2021 at 08:43:16AM -0800, David McMurrey wrote: > Okay, let's say each of my committed files is a chapter in a book, or each > committed file is some piece of Perl code I'm writing. I want to see the > actual HTML page or Perl code ready to use. > > I think my answer is that the actual files in the working directory are the > ones I want to keep and use. I just pull them together say in HTML or Perl > and away we go! I think I assumed that, once committed, you threw away > those files in the working directory. Wrong, right?
Well, I think I understand what you're trying to convey. Let's perform a very basic dive into the Git's "data model", and I think you'll figure out what you want by yourself. What Git does is tracking changes made to sets of files. Sets of files on today's commodity computers are usually organized as directories (also sometimes named "folders") on filesystems; when being a layman person with regard to computers, you might be unaware about the concept of a filesystem but it's hard to avoid dealing with files placed inside folders, right? ;-) Central to Git data model is the concept of a repository. A repository is what is managing a set of files put under the Git's control. You can think of this as a single folder with one or more files in it (and maybe also subfolders with other files under that, and so on, and so on) - with Git allowing to take snapshots of the states of the whole contents of that single folder, with all the contained files and subfolders, and files in them. When you commit in Git, Git records such a snapshot, storing it permanently in the repository in which that commit was made. Recording a commit does nothing to the files. Creating a snapshot of the states of the local files does not somehow "suck them into" such snapshot: committing merely reads the data of the files and stores them into the repository. In other words, this operation is completely read-only for the local files. So, back to your question. Suppose we're writing a document using LaTeX. It might consist of a set of files containing actual document's text and markup, and also may be files defining custom packages, styles etc. You can run any of the tools shipped by LaTeX to compile a final printable document (such as in PDF format) from your source files. In a sense, that document will be the end result of your work but that is not what you manage with Git - you manage the "source" files, as it's they what matter because you can rebuild the final document any time given the source files are there. And now let's consider > I really appreciate your help, Philip and Matt. It's hard to get away from > the files-in-a-directory perspective! ...as you can see, Git _does_ precisely use the files-in-a-directory concept - it just adds "another dimension" to it: it's able to take snapshots of such set of files to allow you to return to any of them, compare them between each other, inspect them etc. Since you appear to be really new to the concept of version control, I'd highly recommend to start with the venerable Git Parable [1] which explains the core concepts behind Git in a really gentle manner. 1. https://tom.preston-werner.com/2009/05/19/the-git-parable.html -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20211222184504.juo5obhnsrzqwtjd%40carbon.
