Jakub Narebski :
> Errr... how did you get that the hash of a commit is not portable???
OK. You're telling me that premise was wrong. Thank you,
accepted.
I've since had a better idea. Expect mail soon.
--
http://www.catb.org/~esr/";>Eric S. Raymond
"Eric S. Raymond" writes:
> Jakub Narebski :
>>> What "commits that follow it?" By hypothesis, the incoming commit's
>>> timestamp is bumped (if it's bumped) when it's first added to a branch
>>> or branches, before there are following commits in the DAG.
>>
>> Errr... the main problem is with d
Elijah Newren :
> Hi,
>
> On Mon, May 20, 2019 at 11:09 AM Eric S. Raymond wrote:
>
> > > For cookie to be unique among all forks / clones of the same repository
> > > you need either centralized naming server, or for the cookie to be based
> > > on contents of the commit (i.e. be a hash functio
Hi,
On 20/05/2019 15:41, Michal Suchánek wrote:
But you were talking as though all those commits
have to be modified*after they're in the DAG*, and that's not the case.
If any timestamp has to be modified, it only has to happen*once*, at the
time its commit enters the repo.
And that's where y
Hi,
On Mon, May 20, 2019 at 11:09 AM Eric S. Raymond wrote:
> > For cookie to be unique among all forks / clones of the same repository
> > you need either centralized naming server, or for the cookie to be based
> > on contents of the commit (i.e. be a hash function).
>
> I don't need uniquess
Derrick Stolee :
> What it sounds like you are doing is piping a 'git fast-import' process into
> reposurgeon, and testing that reposurgeon does the same thing every time.
> Of course this won't be consistent if 'git fast-import' isn't consistent.
It's not actually import that fails to have consis
On 5/20/2019 12:36 PM, Eric S. Raymond wrote:
> Michal Suchánek :
>> On Wed, 15 May 2019 21:25:46 -0400
>> Derrick Stolee wrote:
>>
>>> On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
Derrick Stolee :
> What problem are you trying to solve where commit date is important?
>>
B. Uniqu
Michal Suchánek :
> On Wed, 15 May 2019 21:25:46 -0400
> Derrick Stolee wrote:
>
> > On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
> > > Derrick Stolee :
> > >> What problem are you trying to solve where commit date is important?
>
> > > B. Unique canonical form of import-stream representatio
On Wed, 15 May 2019 21:25:46 -0400
Derrick Stolee wrote:
> On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
> > Derrick Stolee :
> >> What problem are you trying to solve where commit date is important?
> > B. Unique canonical form of import-stream representation.
> >
> > Reposurgeon is a very
On Mon, 20 May 2019 10:14:17 -0400
"Eric S. Raymond" wrote:
> Jakub Narebski :
> > > What "commits that follow it?" By hypothesis, the incoming commit's
> > > timestamp is bumped (if it's bumped) when it's first added to a branch
> > > or branches, before there are following commits in the DAG.
Jakub Narebski :
> > What "commits that follow it?" By hypothesis, the incoming commit's
> > timestamp is bumped (if it's bumped) when it's first added to a branch
> > or branches, before there are following commits in the DAG.
>
> Errr... the main problem is with distributed nature of Git, i.e. w
On Mon, May 20, 2019 at 11:43:14AM +0200, Jakub Narebski wrote:
> You can receive new commits in the repository by creating them, and from
> other repository (via push or fetch). In the second case you often get
> many commits at once.
>
> In [1] it is described how using "bitmap index" you can
On Mon, May 20 2019, Jakub Narebski wrote:
> "Eric S. Raymond" writes:
>> Jakub Narebski :
>
>>> As far as I understand it this would slow down receiving new commits
>>> tremendously. Currently great care is taken to not have to parse the
>>> commit object during fetch or push if it is not nec
"Eric S. Raymond" writes:
> Jakub Narebski :
>> As far as I understand it this would slow down receiving new commits
>> tremendously. Currently great care is taken to not have to parse the
>> commit object during fetch or push if it is not necessary (thanks to
>> things such as reachability bitm
Jakub Narebski :
> As far as I understand it this would slow down receiving new commits
> tremendously. Currently great care is taken to not have to parse the
> commit object during fetch or push if it is not necessary (thanks to
> things such as reachability bitmaps, see e.g. [1]).
>
> With this
Ævar Arnfjörð Bjarmason writes:
> On Thu, May 16 2019, Eric S. Raymond wrote:
>> Derrick Stolee :
>>> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
The deeper problem is that I want something from Git that I cannot
have with 1-second granularity. That is: a unique timestamp on each
c
Philip Oakley :
> > But I don't quite understand your claim that there's no format
> > breakage here, unless you're implying to me that timestamps are already
> > stored in the git file system as variable-length strings. Do they
> > really never get translated into time_t? Good news if so.
> Mayb
Hi Eric,
On 19/05/2019 05:09, Eric S. Raymond wrote:
Philip Oakley :
But I don't quite understand your claim that there's no format
breakage here, unless you're implying to me that timestamps are already
stored in the git file system as variable-length strings. Do they
really never get transla
On 16/05/2019 00:40, Eric S. Raymond wrote:
Jason Pyeron :
If we take the below example:
committer Name 1557948240 -0400
and we follow the rule that:
1. any trailing zero after the decimal point MUST be omitted
2. if there are no digits after the decimal point, it MUST be omitted
This wo
On Thu, May 16 2019, Eric S. Raymond wrote:
> Derrick Stolee :
>> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
>> > The deeper problem is that I want something from Git that I cannot
>> > have with 1-second granularity. That is: a unique timestamp on each
>> > commit in a repository.
>>
>> This
On Wed, May 15, 2019 at 10:20:03PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Since this is going to have to happen anyway
>
> The SHA-1 <-> SHA-256 transition is planned to happen, but there's some
> strong opinions that this should be *only* for munging the content for
> hashing, not adding new
Derrick Stolee :
> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
> > The deeper problem is that I want something from Git that I cannot
> > have with 1-second granularity. That is: a unique timestamp on each
> > commit in a repository.
>
> This is impossible in a distributed version control system
Jason Pyeron :
> If we take the below example:
>
> committer Name 1557948240 -0400
>
> and we follow the rule that:
>
> 1. any trailing zero after the decimal point MUST be omitted
> 2. if there are no digits after the decimal point, it MUST be omitted
>
> This would allow:
>
> committer Name
Derrick Stolee :
> What problem are you trying to solve where commit date is important?
I don't know what Jason's are. I know what mine are.
A. Portable commit identifiers
1. When I in-migrate a repository from (say) Subversion with
reposurgeon, I want to be able to patch change comments so tha
Ævar Arnfjörð Bjarmason :
> You put it key-values in the commit message and read it back out via
> git-interpret-trailers.
Speaking as a person who has done a lot of repository migrations, this
makes me shudder. It's fragile, kludgy, and does not maintain proper
separation of concerns.
The featu
On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
> Derrick Stolee :
>> What problem are you trying to solve where commit date is important?
>
> I don't know what Jason's are. I know what mine are.
>
> A. Portable commit identifiers
>
> 1. When I in-migrate a repository from (say) Subversion with
>
On 5/15/2019 7:32 PM, Eric S. Raymond wrote:
> Derrick Stolee :
>> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
>>> The deeper problem is that I want something from Git that I cannot
>>> have with 1-second granularity. That is: a unique timestamp on each
>>> commit in a repository.
>>
>> This is im
On Wed, May 15 2019, Derrick Stolee wrote:
> On 5/15/2019 4:28 PM, Jason Pyeron wrote:
>> (please don’t cc me)
>
> Ok. I'll "To" you.
I'm a rebel!
>> and we follow the rule that:
>>
>> 1. any trailing zero after the decimal point MUST be omitted
>> 2. if there are no digits after the decimal p
On 5/15/2019 4:28 PM, Jason Pyeron wrote:
> (please don’t cc me)
Ok. I'll "To" you.
> and we follow the rule that:
>
> 1. any trailing zero after the decimal point MUST be omitted
> 2. if there are no digits after the decimal point, it MUST be omitted
>
> This would allow:
>
> committer Name
(please don’t cc me)
> -Original Message-
> From: Derrick Stolee
> Sent: Wednesday, May 15, 2019 4:16 PM
>
> On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
I disagree with many of Eric's reasons - and agree with most of
Derrick's refutation. But
>
> Changing the granularity of timestam
On Wed, May 15 2019, Eric S. Raymond wrote:
> The recent increase in vulnerability in SHA-1 means, I hope, that you
> are planning for the day when git needs to change to something like
> an elliptic-curve hash. This means you're going to have a major
> format break. Such is life.
Note that mo
On 5/15/2019 3:16 PM, Eric S. Raymond wrote:
> The deeper problem is that I want something from Git that I cannot
> have with 1-second granularity. That is: a unique timestamp on each
> commit in a repository.
This is impossible in a distributed version control system like Git
(where the commits a
32 matches
Mail list logo
