Michael Haggerty <mhagger@alum.mit.edu> writes:
> So let's take the simplest example: a branch BRANCH1 is created from
> trunk commit T1, then some time later another FILE1 from trunk commit T3
> is added to BRANCH1 in commit B4. How should this series of events be
> represented in a git repository?
> ...
> The "exclusive" possibility is to ignore the fact that some of the
> content of B4 came from trunk and to pretend that FILE1 just appeared
> out of nowhere in commit B4 independent of the FILE1 in TRUNK:
> T0 -- T1 -- T2 -------- T3 -- T4 TRUNK
> \
> B1 -- B2 -- B3 -- B4 BRANCH1
> This is also wrong, because it doesn't reflect the true lineage of FILE1.
Maybe not, but that *is* how things appeared in the CVS history, and
we'd rather have a git history that looks like the CVS history than
one that claims that boatloads of utterly unrelated commits are part
of a branch's history.
The "inclusive" possibility might be tolerable if it restricted itself
to mentioning commits that actually touched FILE1 in between its
addition to TRUNK and its addition to BRANCH1. So far as I can see,
though, cvs2git is mentioning *every* commit on TRUNK between T1 and B4
... not even between T3 and B4, but back to the branch point. How can
you possibly justify that as either sane or useful?
regards, tom lane