Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi Tomas,
>
> Tomas Volf <~@wolfsden.cz> writes:
>
>> * gnu/packages/version-control.scm (cgit): Update to 1.2.3-7.751a5b5.
>>
>> Change-Id: I3f4d27246065d67a258a8cf3b3dea2e0b2d2bc9f
>> ---
>>  gnu/packages/version-control.scm | 10 +++++-----
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm
>> index 3339e79390..28afcfa2ff 100644
>> --- a/gnu/packages/version-control.scm
>> +++ b/gnu/packages/version-control.scm
>> @@ -1345,8 +1345,8 @@ (define-public git-remote-gcrypt
>>     (license license:gpl3+)))
>>
>
> Usually, we request that a comment is added to explain why a particular
> unreleased commit must be used instead of the latest release.

This was not requested 11 months back when I did the initial upgrade,
but fair enough.  Shall I send a separate patch adding the comment?

> Would it be possible to remove the commit/rev variables and switch
> back to use the latest release?  It's not clear why we aren't doing
> that.

Possible?  Sure.  Good idea?  Not in my opinion.  Last release is from 5
years ago, and there were many bug fixes since then.  Even sites like
git.kernel.org do not use the last release.

Have a nice day,
Tomas Volf

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.