Michal Suchánek <[email protected]>:
> On Wed, 15 May 2019 21:25:46 -0400
> Derrick Stolee <[email protected]> wrote:
>
> > On 5/15/2019 8:28 PM, Eric S. Raymond wrote:
> > > Derrick Stolee <[email protected]>:
> > >> What problem are you trying to solve where commit date is important?
>
> > > B. Unique canonical form of import-stream representation.
> > >
> > > Reposurgeon is a very complex piece of software with subtle failure
> > > modes. I have a strong need to be able to regression-test its
> > > operation. Right now there are important cases in which I can't do
> > > that because (a) the order in which it writes commits and (b) how it
> > > colors branches, are both phase-of-moon dependent. That is, the
> > > algorithms may be deterministic but they're not documented and seem to
> > > be dependent on variables that are hidden from me.
> > >
> > > Before import streams can have a canonical output order without hidden
> > > variables (e.g. depending only on visible metadata) in practice, that
> > > needs to be possible in principle. I've thought about this a lot and
> > > not only are unique commit timestamps the most natural way to make
> > > it possible, they're the only way conistent with the reality that
> > > commit comments may be altered for various good reasons during
> > > repository translation.
> >
> > If you are trying to debug or test something, why don't you serialize
> > the input you are using for your test?
>
> And that's the problem. Serialization of a git repository is not stable
> because there is no total ordering on commits. And for testing you need
> to serialize some 'before' and 'after' state and they can be totally
> different. Not because the repository state is totally different but
> because the serialization of the state is not stable.
Yes, msuchanek is right - that is exactly the problem. Very well put.
git fast-import streams *are* the serialization; they're what reposurgeon
ingests and emits. The concrete problem I have is that there is no stable
correspondence between a repository and one canonical fast-import
serialization of it.
That is a bigger pain in the ass than you will be able to imagine unless
and until you try writing surgical tools yourself and discover that you
can't write tests for them.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
