On Thu, Aug 13, 2015 at 12:12 PM, Mike Frysinger <vap...@gentoo.org> wrote: > On 13 Aug 2015 10:36, William Hubbs wrote: >> I understood the usefulness of this line to some when we were using CVS >> since it expanded into the ebuild revision, date, etc. >> >> This expansion doesn't take place under git, so now I don't understand >> the usefulness of this line. If I have missed something, can someone >> fill me in, or if it isn't useful any more can we consider removing it? > > delete it and be done
When I asked a few days ago the arugment was made that it will be expanded when the ebuilds hit rsync, and then users can reference these when submitting bugs so that devs know what revision they're using/etc. It was stated that this was a highly-requested feature. I'm still personally leaning towards delete it and be done for a few reasons: 1. If the user syncs from git and not from rsync (which I suspect will be come steadily more popular - git is very efficient at syncing though it takes more space), then they won't get the hash, though they can of course just ask git for it. 2. Users don't routinely attach ebuilds to bugs, so we'll still be pestering them for this info. 3. That hash doesn't provide any kind of at-a-glance info anyway. You're going to to have to ask git what it is. It is a unique ID for the file though. I think IDs embedded in files make more sense for workflows that envision a lot of out-of-git work, since they tie back into the git tree. If you stay in git all the time, they're redundant. But, the biggest reason IMHO is that it is in-band signaling and I can forsee all the issues we ran into with cvs keywords. The git validation and migration work constantly ran into this as probably our #1 unfixable problem, and Robin's go-live emails indicated that we still had tons of patches that had keyword expansion issues. The job of an scm should be to store files and regurgitate them on request. If you ask it to also mangle their contents you're inevitably asking it to mangle their contents in ways you didn't forsee. -- Rich
