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