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