| 1 |
Danny van Dyk wrote: |
| 2 |
>> In practice I find it's rare that a user has been hacking around in |
| 3 |
>> the eclasses. All the SHA1 tells you is that it's not the most |
| 4 |
>> recent, but it's not easy to determine from the SHA1 exactly which |
| 5 |
>> version they do have (so it's not enough to determine what's |
| 6 |
>> different). |
| 7 |
>> |
| 8 |
>> Having said that, the most accurate way to find out what they have is |
| 9 |
>> to get them to attach the eclass and diff it yourself. However |
| 10 |
>> relying on the SHA1 also means you can't just say things like, "Check |
| 11 |
>> eclass <blah> is version 1.836 (look at the "$Header" line at the top |
| 12 |
>> of the file)." |
| 13 |
> |
| 14 |
> In the case of GIT you can just use 'git diff SHA1SUM' to see what has |
| 15 |
> changed or 'git log SHA1SUM..HEAD' to show a list of revisions in |
| 16 |
> between. So _if_ we changed to git, this would be no problem as long as |
| 17 |
> every user has sha1sum installed [which is part of coreutils]. |
| 18 |
> |
| 19 |
Well since that appears to be some way off, is there any way to get the |
| 20 |
needed functionality (version string inside ebuild) without a double |
| 21 |
commit? (Did i read that right?) I'm thinking at worst someone might have |
| 22 |
to add something to repoman, or a hook on the server end. |
| 23 |
|
| 24 |
|
| 25 |
-- |
| 26 |
gentoo-dev@g.o mailing list |
Archives