Re: [RFC/PATCH v4 2/2] gitweb: append short hash ids to snapshot files
- From
Mark Rada <marada@uwaterloo.ca>
- Date
- Sep 13, 2009, 05:39 UTC
- Message-ID
- <4AAC85AC.9080004@mailservices.uwaterloo.ca>
- In-Reply-To
- <7v7hw34ivl.fsf@alter.siamese.dyndns.org>
On 09-09-12 11:35 PM, Junio C Hamano wrote:
Show 10 quoted lines
>> @@ -5207,6 +5227,12 @@ sub git_snapshot {
>> ...
>> +
>> + if ($full_hash !~ /$hash/) {
>> + $hash .= '-' . git_get_short_hash($project, $hash);
>> + } else {
>> + $hash = git_get_short_hash($project, $hash);
>> + }
>
> I do not get this test. What is this unanchored pattern match about?I missed that, it should have been anchored.
Show 26 quoted lines
> I do not think you wanted to allow matching a partial 1234567 $hash to
> substitute a full 01234567..... $full_hash, so I am guessing that you
> meant to say "$full_hash !~ /^$hash/" at least, or perhaps you meant even
> "$full_hash ne $hash".
>
> But that still does not make much sense to me. Perhaps you meant to catch
> a case where $hash is a tagname (or refname), i.e. $hash = 'v1.6.3' or
> $hash = 'next'?
>
> If that is indeed the case, then perhaps you should check for that more
> explicitly, perhaps using "git show-ref $hash" or something. I do not
> know if the complexity (not just the "detect handcrafted $hash string that
> is not an SHA-1", but this whole "give shorten one" topic) is worth it,
> though. And if you drop the hunk that changes user supplied $hash to
> $full_hash in the output file name in your [PATCH 1/2], I do not think you
> need this anyway. If somebody asked for 'next', he will get 'next'.
>
> If somebody asked for 01234... (full 40 hexdigits) because that was the
> link on the gitweb output page, it might make sense to give him a
> shortened name, but then the above conditional needs to be only:
>
> if ($full_hash eq $hash) {
> $hash = git_get_short_hash($project, $hash);
> }
>
> no?This was a manifestation of a suggestion from Jakub:
Show 13 quoted lines
> Second, I'd rather have better names for snapshots than using full SHA-1. > For snapshot of 'v1.5.0' of repository 'repo.git' I'd prefer for snapshot > to be named 'repo-v1.5.0', and for snapshot of 'next' branch of the same > project to be named for example 'repo-next-20090909', or perhaps > 'repo-next-2009-09-10T09:16:18' or 'repo-next-20090909-g5f6b0ff', > or 'repo-v1.6.5-rc0-164-g5f6b0ff'. > > I'm not sure what would be the best name of snapshot of given > subdirectory... > > > In short: I'd rather not improve on bad design of using full SHA-1 > in snapshot name.
For me, there are two fates that snapshots will end up with: being deleted as soon as I have unrolled the contents, or long term archiving. For the latter case, it is nice to have an idea of when it came from, though I guess I should have appended a date in that case... ¯\(°_o)/¯
Thoughts?
Show 25 quoted lines
>> +test_commit \ >> + 'SnapshotFileTests' \ >> + 'i can has snapshot?' >> +test_expect_success \ >> + 'snapshots: give full hash' \ >> + 'ID=`git rev-parse --verify HEAD` && >> + gitweb_run "p=.git;a=snapshot;h=$ID;sf=tgz" && >> + ID=`git rev-parse --short HEAD` && >> + grep ".git-$ID.tar.gz" gitweb.output' > > I'd rather see these indented like: > > test_expect_success 'snapshots: give full hash' ' > ID=$(git rev-parse --verify HEAD) && > gitweb_run ... > ' > > Also, if I am not mistaken, "test_commit" is not about doing any test, but > is a short-hand for doing an operation, right? It would be better to have > it inside test_expect_success just in case your "git commit" or some other > commands are broken. I.e. like > > test_expect_success 'create a test commit' ' > test_commit SnapshotFileTests "Can I have shapshot?" > '
Can I have snapshot?!?! What do you have against LOLspeak? :P
-- Mark Rada (ferrous26) marada@uwaterloo.ca