Re: [PATCH] Make reflog query '@{1219188291}' act as '@{2008/08/19 16:24:51}'
- From
Alex Riesen <raa.lkml@gmail.com>
- Date
- Aug 20, 2008, 20:09 UTC
- Message-ID
- <20080820200912.GG16626@blimp.local>
- In-Reply-To
- <20080820200026.GK3483@spearce.org>
Shawn O. Pearce, Wed, Aug 20, 2008 22:00:26 +0200:
Show 15 quoted lines
> Alex Riesen <raa.lkml@gmail.com> wrote:
> > Shawn O. Pearce, Wed, Aug 20, 2008 21:44:07 +0200:
> > >
> > > We could pick any number for the limit, just so long as its so
> > > large that the size of the reflog for it to be a valid @{nth}
> > > request would be something like 1 TB, and thus be highly unlikely.
> > >
> > > I was just trying to be cute by using the original commit timestamp
> > > of Git itself. Perhaps 12936648 (1TB / 83)?
> >
> > How about the maximum value the platform's size_t can handle?
>
> So on 64 bit platforms we need to wait for another 2.92277266
> x10^10 years before we will ever see a seconds-since-epoch which
> can't possibly be mistaken for a position in the relfog file?It is just a timestamp. Can be set to anything.
Show 7 quoted lines
> > Not because it is "highly unlikely", but because you and me frankly > > have no idea exactly how unlikely for example a "12936648 terabytes" is? > > I have half a brain. Creating 12 million reflog entries would > typically require 12 million git-update-ref forks. Anyone who is > doing that many since reflog was introduced and has not yet truncated > their reflog _really_ should reconsider what they are using it for.
Why? It may just as well work (unless there are some other, more technical restrictions).
> Evaluating foo@{12936648} will be _horribly_ expensive. Anyone whoDepends what you evaluate it on. 640kb was also more than enough for anyone once.
Show 5 quoted lines
> is waiting for that result and _cares_ about it would have already > started asking on the list for a reflog which is not based on a > flat file. If they have already patched their Git to use something > else (e.g. gdbm) I have no pity for them when this changes/breaks > as they clearly have already patched their Git rather heavily.
Why should you _care_?