Re: git branches

["J. Lewis Muir" <jlmuir%imca-cat.org@localhost>]

On 1/17/15 5:17 PM, David Holland wrote:
> On Wed, Jan 14, 2015 at 02:58:59PM -0500, Eric S. Raymond wrote:
>  > 2 is incorrect. Branch-ordering data is not "thrown away" in
>  > fast-import streams, it's sufficiently expressed by the distinction
>  > between "parent" and "merge" ops. Without that distinction,
>  > correctly re-coloring the Git DAG would be impossible. With it, you
>  > can perfectly recover CVS-like commit IDs.
>
> Yes, it is. The input (the CVS repository) contains what this
> discussion has been called branch coloring data; the output (the
> fast-import stream) does not contain this data. Therefore it's been
> thrown away.
>
> Whether you can or can't reconstruct it correctly again later is
> orthogonal to whether it's been thrown away.

Hello, David and Eric.

If you think of the fast-import stream as an encoding of the data, the
real question is whether the encoding is lossy or lossless.  If the
fast-import stream can be decoded perfectly into the original data, then
it's lossless, and that's what matters.  If a particular data value is
not explicitly represented in the encoded form but can be recovered
nonetheless, the encoding is still considered lossless.

>  > 3 is incorrect.  You can both recover the branch coloring and
>  > reconstruct merge commits.  The only thing you cannot do is,
>  > *after* translation, add a merge commit and branch-color it without
>  > making an assumption about which ancestor represents the "real"
>  > line of development that may be wrong.
>
> Once you have manufactured some merge commits, when reconstructing and
> you cross a merge commit going backwards, how do you know which of the
> ancestors is the same branch and which is another? And how do you know
> which other branch it is? I don't see that the git-fast-import format
> can preserve this information, any more than it preserves per-commit
> branch metadata.

I think the discussion has been *very* good so far, but I know it has
soured a bit now.  I wish it wouldn't end like this, though!  Perhaps
a way forward is to, rather than talking in the abstract, talk about
something concrete.  David, you could construct a small CVS repository
exhibiting the characteristics of concern, and Eric, you could run your
tools on it, and we could see what the result is.  This might make it
easier to discuss the concerns.  How about it?

Regards,

Lewis