On Fri, Feb 26, 2021 at 9:35 AM Ed Maste <[email protected]> wrote: > On Thu, 25 Feb 2021 at 15:58, Warner Losh <[email protected]> wrote: > > > > The problem, though, can happen when you run a shallow clone or gitup to > > get the sources and build from that. In that case the v number is bogus > > (hmmm, we should omit it when we have a shallow clone maybe). > > I want to clarify one point here - the commit count is already omitted > from uname in the case of shallow clones (as Kevin Oberman > discovered). > > Shallow clones certainly have the benefit of limiting the amount of > disk space used by the clone. Does that outweigh the loss of the > commit count? > > I had a look at the size of the .git directory with different --depth > settings: > > 262M stable-13-shallow-1/.git > 262M stable-13-shallow-10/.git > 262M stable-13-shallow-100/.git > 281M stable-13-shallow-1000/.git > 807M stable-13-shallow-10000/.git > > I think we can provide a way to include the commit count as long as > we're willing to require some minimum clone depth, and will pursue > this in the next while. If this works out it will make it into > stable/13, but probably not releng/13.0. >
The count is a count back to the first commit in the repo. There's not even a clear design for how to accomplish that with a subset of the repo that's been floated. It might be possible, but until we have a clearly articulated plan, it may be a bit premature to set expectations that it might happen. I'm happy to be proven wrong, of course, and once there's a clear way to accomplish this that's not fragile or a large maintenance burden on the project, I'll happily support it... Warner _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[email protected]"
