[ For those in a hurry: Do get the Pro Git book, maybe watch the Linus and Scott videos. They helped me "get it", and wish to never go back to a life without git. :-D Seriously! ]
On Sun, 2022-06-05 at 22:59 -0700, Brian Buhrow wrote: > > [ ... ] I should preface my comments with the caveat that I am > not by any means a git expert, and, in fact, I'm barely able to > get anything I want out of it. With that said, here are my > questions and observations. [ ... ] There is no problem with that I assume. From personal experience I can tell that git takes some getting used to. But once you do you don't want to go back. Seriously. It's just that approaching git with svn or cvs in mind feels tedious, while it need not. Accepting that git is a different tool with a different philosophy is important. But I'm preaching to the choir here, since this is a Unix ML. :) Have been struggling with git for several years myself. Couldn't get it. Was lost. The cheat sheets and cook books did not help. References are not useful if you don't know what to look for. Did not like that situation. This must have been some two or three years of "fighting" git, and Unix people know that users don't win in that setup. The Pro Git book was the first document that helped me. A lot. See git-scm.org -> book. Takes you to https://git-scm.com/book/en/v2 right now. Do yourself a favour and do _not_ skip any of the first two chapters. Learning how git works internally enables you to use it in ways that you haven't dreamed of before. No kidding. If the book doesn't work for you (could be, not everybody is the same), it's worth a try nevertheless. The concepts are simple, Linus created the first working version of the tool in two weeks. Later the UI has improved but the concepts have proven stable. Another useful resource, faster to watch than reading the book, could be Linus' and Scott's videos. See git-scm.org -> doc -> external links -> bottom. Linus (the initial git author) at Google https://www.youtube.com/watch?v=4XpnKHJAok8 and Scott (github employee, author of the great Pro Git book) giving an overview of essential commands. May be a challenge regarding the audio track, but native speakers may bother less or not notice at all. Don't get put off by opinions, the points raised are valid, and precious to keep in mind. With that being said first, let's see the questions that you raised. > 1. In CVS, I can do something like: > cvs log sys/dev/pci/if_bge.c > and be given a complete history of the changes to that file, as > well as a list of all the branches that file participates in > and which versions apply to each branch. And, I can do this > without having to download all of the history of that file onto > my local storage. As others said it's an essential part of the design that git operates on a local clone. It's the very essence of a distributed system. The assumption is that disk space is cheaper than network traffic. Experience strongly suggests that local disk access is faster than a remote server. Being able to work offline is a byproduct, though a very nice one. Linus talks about this aspect. It's not just an arbitrary implementation detail, it's really essential, and enables you in unseen ways. Tracking single files is what he doesn't actually do, but being able to track an individual file from the complete tree's history is what you get as a byproduct. Changes your mind once you see it (again, not kidding). Others stated that the copy may be rather efficient, could even be smaller than what you got today with other systems. It's deduplicated, and compressed. Worth checking, you may be surprised. Works for projects like KDE and others. When you got some local copy, subsequent copies optionally can reference it. Saves both disk space and network traffic. Am using the --reference option here extensively (notebook, SSD, useful). Others use caching proxies in their lab or classes. Or something on your local server that just git clones (optionally bare) and that you clone from to your workstation. Works transparently. Because: distributed, by design. Sparse downloads are supported, too, as others noted. But these are more popular in build setups that are not interested in the history, only want the current state. A regular clone gets you the full history, by design. From local disk. Fasten your seat belt. :) Also lets you switch between branches and revisions within seconds. (Developers may find bisection a killer feature that they never want to miss again.) > 2. Also, in my exploration of git, it seems like the git log > command shows all the commits for each tag, rather than the > comments for a specific file or object in the repository. > Again, is this correct? Am finding myself looking up a lot of 'git --help', and 'git <cmd> --help'. Alternatively use 'man git-<cmd>'. Reoccuring subjects need not be discussed in detail in every individual command's page. There are generic subjects, the 'git --help' output refers to these as "concepts". You may be looking for gitrevisions(7) perhaps. Git lets you express things that may not map to cvs' capabilities. Go explore. I find myself using some of these phrases, others I haven't inhaled yet. It's similar to vim and other tools, everyone finds a working set that works for him in his environment. Others mentioned that for git-log specifically the syntax is $ git log [commit-ish] -- [file/dir]... or similar. And yes you will quickly accumulate a ~/.gitconfig file with several aliases. You know best what you keep using all day. Format options are another area to customize and alias (think -p, --stat, file names, --format=fuller, ISO date, etc). Other features that you may never want to miss could be interactive add, interactive rebase, and bisection as mentioned above. Lots to explore. Don't assume that git would just be a different kind of subversion, it so totally is not. Another important thing that I notice when people ask questions: Don't let others tell you that there is just one way, don't try to come up with the most clever and the shortest (read: maximum terseness) command. Just get a few concepts in your head, pick up a working set of primitives, and combine these. After some 15 years of git use I don't have everything in my head either. Just take the steps that get you to where you want to go to. Being confident that your small or wide strided steps do take you there is nice, I like it. Another great experience: You have to twist and bend before you lose data, it's actually hard to do that with git. There are a few "dangerous" commands (some three of them in total I guess), and they have red flags so that you will be aware. But the majority of git commands just adds to the metadata. And you got means to recover from your mistakes because nothing was really lost. (See reflog et al.) Did I mention that I like git a lot after overcoming the first hurdles? You may have guessed that from the above text. There really are convincing reasons to switch, or to seriously consider one of the distributed systems. It's not that the older tools are bad, they have served the community a long time, and are better than what existed before them. It's just that better tools have become available in the meantime. virtually yours Gerhard Sittig -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
