On Mon, 6 Jun 2022 at 06:59, Brian Buhrow <buh...@nfbcal.org> wrote: > > Hello. At the risk of raising the debate about which version control > system we should > use, I have a question about git, as well as a comment about it relative to > the NetBSD source > tree. 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. I'd be interested to know how others work around > these issues > and/or what you think of my observations. > > 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. > It seems like the only way to do this with a git repository is to > download the entire > source tree, along with its history and branches, using git clone with an > infinite depth. Is > this correct? If not, how can I see all the branches of a given repository > without having to > download the entire repository?
git inherently looks at the local copy of the repo. So your options are - have a local copy - ssh to somewhere with a local copy - use a web tool or similar to browse > 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? You can do either or both - "git log trunk" "git log build.sh" or "git log trunk build.sh" As an aside, I have an alias of gl -> "git log --name-status" as I really prefer to see the filenames changed in each commit > If I am correct in my guesses about how git works, it seems like I > would have to download > the entire history of the NetBSD source tree if I want to browse its > branches, or the commit > history for any given file. This is a lot of overhead to examine tiny > portions of the tree, > relatively speaking, assuming we move to git for our version control system. > It strikes me > that requiring this much storage space from developers, would be a regression > from what we > currently do. Since I think we're smarter than that and since we have very > smart people on our > development team, I want to understand what it is that I don't get about git > that precludes me > from having to download the entire history of the source tree from day one > while still > retaining access to that history over time. "It's a feature". Half :) - Seriously though, the ability to actually browse and search the full history of a source tree as git allows compared to the godawful eye-of-the-needle view that CVS provides is a very valuable benefit of the tradeoff of having a local history. When looking at source tree history I use a cloned copy of the github src, then apply to the CVS tree as needed. For people with limited resources it will be a pain, though there are any number of services which provide remote web access to git trees. Having said that, the ever increasing memory requirements of modern gcc is a much bigger pain for limited resources with a relatively smaller benefit. I suspect most of this also works with s/git/hg/ assuming NetBSD switches to a mercurial repo David