| 1 |
On Fri, Apr 20, 2007 at 08:22:42AM -0400, Mike Frysinger wrote: |
| 2 |
> does anyone actually find this useful ? i think ive used the value in there |
| 3 |
> like once (when in reality a `md5sum` would have worked just as well) ... |
| 4 |
> otherwise, from my perspective: |
| 5 |
> - it causes annoying bogus hunks in diffs |
| 6 |
> - not uncommon for people to contact me as the maintainer because i'm in that |
| 7 |
> - wastes space (well, probably not a strong argument due to bytes vs blocks) |
| 8 |
> - for mostly green users, it's confusing and they get it wrong |
| 9 |
|
| 10 |
This came up in my discussions on the Git mailing list (as something Git |
| 11 |
specifically does not support, as it's 99.9% untenable with the design |
| 12 |
of Git [1]). |
| 13 |
|
| 14 |
The ONLY usage case that seems to exist for $Header$, is that of tracing |
| 15 |
what version of a file was used. In this context, it's handy to tell a |
| 16 |
user that the bug that blocked his install of a package is fixed in CVS |
| 17 |
revision X, and he can just check out the header to see when it's |
| 18 |
available. |
| 19 |
|
| 20 |
Counter-case for this is that the ChangeLog should also be updated (but |
| 21 |
some developers aren't very good about that...), and that can be checked |
| 22 |
too. |
| 23 |
|
| 24 |
Addressing vapier's original issues |
| 25 |
- the hunks can be filtered out with a smarter diff/patch (prototype was |
| 26 |
on the Git ML) |
| 27 |
- It is occassionaly useful for a developer to contact the person |
| 28 |
(!maintainer) that made a given change to an ebuild, but this data is |
| 29 |
in the VCS as well. |
| 30 |
- Space wastage is still a valid concern, we save approximately 119 |
| 31 |
bytes per ebuild (5.3Mb in the current tree). The saving carries very |
| 32 |
nicely into any compressed versions - ~650Kb by my quick estimate. |
| 33 |
|
| 34 |
So I'd be in favour of getting rid of them, if we make sure that |
| 35 |
everybody always commits to the ChangeLog (Make it a repoman failure). |
| 36 |
Side benefit of removing the need to double-commit from the hashes |
| 37 |
changing. |
| 38 |
|
| 39 |
Notes: |
| 40 |
[1] The only keyword that makes sense in the context of git is the SHA1 |
| 41 |
BlobID of a given revision of the file. The SHA1 is based solely on the |
| 42 |
contents with keywords collapsed, and thus it IS legal that a given |
| 43 |
blobid appears several times in the history of a file, or for multiple |
| 44 |
files, but this is irrelevant as the files are identical. |
| 45 |
|
| 46 |
-- |
| 47 |
Robin Hugh Johnson |
| 48 |
Gentoo Linux Developer & Council Member |
| 49 |
E-Mail : robbat2@g.o |
| 50 |
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 |
Archives