[mythtv] Github tarball from commit can change

[Alec Leamas]

On 28/09/15 17:01, Craig Treleaven wrote:
>> On Sep 28, 2015, at 9:19 AM, Alec Leamas <leamas.alec at gmail.com> wrote:
>>
>> On 28/09/15 14:34, Stuart Auchterlonie wrote:
>>
>>> Pulling the tar ball will always pull the latest and greatest.
>>> Any change to fixes/0.27 will result in a different tarball to
>>> the previous download.
>>>
>>> There may be a way of telling it to pull at a specific commit,
>>> but haven't looked at it
>>
>> There is. See e. g.,
>>
>> https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#Git_Hosting_Services
>
> Thanks, Alec, that is what I am doing except that I just use the short hash (“e9b577d3”) rather than the 40-character full hash.  If I should be using the full hash, I can do that.
>
> AIUI, this causes GitHub to deliver a compressed tarball of a snapshot of the project as of that commit.  GitHub creates these tarballs and caches them for some unknown length of time.  GitHub _should_ be able to re-create the tarball if the cached version is no longer available since the snapshot should be exactly the same.

As I understand this, github just uses git-archive(1) to retrieve the 
tarball. We have noted that they have the specific semantics described 
in the manpage about checking out a commit vs checking out a version/tag.

> My WAG is that the file that differs (‘EXPORTED_VERSION’) is generated by a git hook.  It may be that the hook works differently depending on whether the commit hash is the lastest in that branch or not.  I know almost nothing about such hooks, however, so I could be entirely wrong.

If so, I would be surprised if github is involved in this. As I 
understand it, EXPORTED_VERSION is a myth thing. I suppose anything is 
possible, but it should then be that someone has installed a hook on the 
github side. Unfortunately, this is above my paygrade :(

My understanding is that if you checkout the same commit (with a direct 
reference, not using any tag/version) you should get exactly the same 
files, checked by a hashsum. If you reference a tag the files should be 
the same but the modification dates are different.

So, someone has tampered with EXPORTED_VERSION. First question is if 
it's actually part of the archive or generated by myth, isn't it?
'git ls-files' or 'git log EXPORTED_VERSION' in a cloned copy should 
reveal that, I guess.

Actually, you could also run git-archive(1) directly from a clone as 
well. AFAICT, this is the same as pulling a copy from github.


Cheers!

--alec