Re: Slightly off topic, question about git

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

[ incomplete list of git features that a BSD developer may like ]

On Mon, 2022-06-06 at 14:40 +0200, Gerhard Sittig wrote:
>
> [ ... Brian Buhrow asked for useful access to VCS history ... ]

Your question started with a specific command accessing the
information for a single file ('cvs log sys/dev/pci/if_bge.c').
There could be something else that you intend perhaps. Let's see
whether these things help you, too.

There is 'git describe' that lets you see what you currently are
looking at. Typically results in the most recent tag plus a
number of commits and the resulting hash of what you specified as
input. Can be helpful to tell you how far your development has
gone since a release.

There is 'git describe --contains' which tells you which next tag
(read: a released version) contains a specific commit (read: a
fix or new feature or changed behaviour). This is useful for
maintenance, and the reason why some mention "Fixes: <hash>" in
their commit messages, so that other people or machinery can tell
whether their stable release needs updating/amending.

That git thinks of the whole content of the tree, and that a
filter is applied to narrow the result set when you specify dirs
or files, was mentioned before. Changes your perspective.

Tinker with 'git log' options, there are tons of them, and your
needs will differ depending on which situation you are in. One
aspect is "the zoom level": --oneline alone for bird's view, no
spec for author/date/message, -p to include the content change.
Others are --reverse, --format=, --name-status, --staged, etc.
The --stat option is very useful for reviewers/maintainers.

I don't like the 'git blame' name, because it's additional
information that I'm looking for and not a guilty person. :)
That's why I got an 'ann' alias to invoke 'blame'.

The default 'git status' output is very helpful if you are
looking for help on what to do next. But terrible to digest in
quick iterations. 'git status -s' helps parse that stuff. And
I feel that 'git commit -v' should be the default. To help create
useful commit messages.


Other things that can help the BSD projects regardless of whether
the decentralized development model is considered a fit:

Bisection lets you quickly navigate to a commit of interest. When
HEAD works for you, and an older version is said to have an
issue, then 'git bisect' lets you identify the commit which
probably introduced the change in behaviour. Either driven by a
human and supported by the machine, or fully automated if you
have a test condition which the machine can check for you. This
reduces a set of 10k changes between two releases to some 15
steps that you need to look at, before your attention is where
it needs to be. Of course this depends on whether a one-liner
enables something that got introduced a few hundred commits
before that which just did not take effect immediately. But it
helps you narrow in to what you should be looking at. Linear
history helps there. That's again why rebase is useful.

Interactive add ('git add -u -p', and 'git reset -p' before 'git
commit') lets you separate unrelated changes into individual
commits as they should be. Without tediously copying files around
or losing part of what you accumulated. Interactive rebase ('git
rebase -i') lets you create a proper patch series that others can
digest during review, and reason about why it's desirable to pick
up. Rebasing is useful in these iterations before submission, and
what ends up in the mainline project is clean and maintainable.

Showing other people you local changes could be done by pushing
to a public place. Or by the 'git format-patch -o $DIR $BASE..'
command. The counterpart is 'git am' (apply a set of changes).
Even if you don't do the "popularity contest" among several
mainlines(?) that others suggested, it's a useful feature to have
between involved developers. The result would be similar to
patches that currently are attached to emails, just easier to
review and test perhaps. There is 'git apply' if you have a patch
that is not git-am formatted.

'git diff' has a few options that can make it more pleasant to
view than mere diff(1) output. But that's cosmetics. Diffstats
are very useful to have once you get familiar with them.


This is not an attempt to cram git down your throat just because
I happen to like it after getting to know it. It's a plea to
consider whether the tool could help you in ways that you haven't
seen before, before assuming that "these people" don't know how
to create a proper tool because it's different from what you used
so far in your daily routine.

The reason why git is different is that no other tool matched the
Linux kernel development model with its thousands of mostly
disconnected participants. The tool still can be applied in a
centralized manner (many companies do), and can be more
convenient than other tools. I'm often using git to communicate
to a subversion server. Don't know if there is a similar bridge
for CVS (outside of repo migration to become git based, you may
not want to start with that, neither affect other people just
because you start to experiment with git).

And do not mistake github.com the service provider or its many
unaware users as representative for git-scm.org the tool and
concept. Though I can see how github enables those who otherwise
would never have shared, or used a VCS at all, I strongly
disagree with many things that are done at this site. But
following that reasoning you could claim that the C language is
dangerous and unusable just because a lot of terrible code
exists. It's not the fault of the language, experienced
developers can create beautiful results with it. And you are
aware of this fact. :-]


</soapbox>

Hope the above list of features that could be applicable to BSD
development is more helpful than the "ranting" which may have
bothered you along the way. This is how I ended my earlier
message:

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