Re: Slightly off topic, question about git

[Gerhard Sittig <gerhard.sittig%gmx.net@localhost>]

[ 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.