Hello,
Marius Bakke skribis:
> I like the "git describe" format:
>
> $ git describe
> v0.16.0-414-ge99d036828
I’d love that. We just need to add the missing bindings to Guile-Git.
Hint hint. ;-)
As for the date, note that ‘guix describe’ displays the generation’s
date already.
Thanks,
Ludo’
Am 30.12.18 um 03:48 schrieb Vagrant Cascadian:
> The problem with dates from git commits is that git makes no attempt to
> keep commits in cronological order, and timezone adds interesting issues
> to the mix. For example:
Though *author* dates might not be in cronological order, *commit* dates
a
On 2018-12-26, Gábor Boskovits wrote:
> swedebugia ezt írta (időpont: 2018. dec. 25., K,
> 22:39):
>> On 2018-12-25 20:49, Taylan Kammer wrote:
>> > Currently, after running 'guix pull', the Guix version will be reported
>> > by 'guix --version' as something like:
>> >
>> > 522d1b87bc88dd459
On Sat, 29 Dec 2018 23:50:11 +0100
Ricardo Wurmus wrote:
> swedebugia writes:
>
> > "Björn Höfling" skrev: (29
> > december 2018 12:53:04 CET)
> >>On Thu, 27 Dec 2018 22:30:11 +0100
> >>Taylan Kammer wrote:
> >>
> >>> I like dates in "rolling release" version strings because they
> >>> im
swedebugia writes:
> "Björn Höfling" skrev: (29 december 2018
> 12:53:04 CET)
>>On Thu, 27 Dec 2018 22:30:11 +0100
>>Taylan Kammer wrote:
>>
>>> I like dates in "rolling release" version strings because they
>>> immediately tell you how old/new the version is, but I can certainly
>>> live wi
"Björn Höfling" skrev: (29 december 2018
12:53:04 CET)
>On Thu, 27 Dec 2018 22:30:11 +0100
>Taylan Kammer wrote:
>
>> I like dates in "rolling release" version strings because they
>> immediately tell you how old/new the version is, but I can certainly
>> live with that format too. Definitely be
On Thu, 27 Dec 2018 22:30:11 +0100
Taylan Kammer wrote:
> I like dates in "rolling release" version strings because they
> immediately tell you how old/new the version is, but I can certainly
> live with that format too. Definitely better than what we have.
I also would prefer a string containin
I like dates in "rolling release" version strings because they
immediately tell you how old/new the version is, but I can certainly
live with that format too. Definitely better than what we have.
- Taylan
On Wed, Dec 26, 2018 at 3:02 PM Marius Bakke wrote:
>
> swedebugia writes:
>
> > On 2018-1
swedebugia writes:
> On 2018-12-25 20:49, Taylan Kammer wrote:
>> Currently, after running 'guix pull', the Guix version will be reported
>> by 'guix --version' as something like:
>>
>> 522d1b87bc88dd459ade51b1ee0545937da8d3b5
>>
>> I think it would be really nice if instead it were someth
Hello,
swedebugia ezt írta (időpont: 2018. dec. 25., K, 22:39):
>
> On 2018-12-25 20:49, Taylan Kammer wrote:
> > Currently, after running 'guix pull', the Guix version will be reported
> > by 'guix --version' as something like:
> >
> > 522d1b87bc88dd459ade51b1ee0545937da8d3b5
> >
> > I thin
On 2018-12-25 20:49, Taylan Kammer wrote:
Currently, after running 'guix pull', the Guix version will be reported
by 'guix --version' as something like:
522d1b87bc88dd459ade51b1ee0545937da8d3b5
I think it would be really nice if instead it were something like:
2018-12-25-522d1b
wher
Currently, after running 'guix pull', the Guix version will be reported
by 'guix --version' as something like:
522d1b87bc88dd459ade51b1ee0545937da8d3b5
I think it would be really nice if instead it were something like:
2018-12-25-522d1b
where the date is the commit's date (year, month,
12 matches
Mail list logo
