Re: git: uh-oh

Tom Lane wrote:
> Michael Haggerty <mhagger(at)alum(dot)mit(dot)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?

There is no way, in git, to claim that (say) T3 was incorporated into B4
but that T2 was not. If T3 is listed as a parent of B4, then it is
implied that all ancestors of T3 are also incorporated into B4. This is
a crucial simplification that helps DVCSs merge reliably. So an
"exclusive" option is definitely the way to go for the postgresql project.

[By the way, it *is* possible to list the commits that touched FILE1:

git log BRANCH1 -- FILE1

The user would first have to find out that FILE1 is the file that is the
subject of merge B4, which could be done using "git diff B3..B4". But I
am not arguing that this is the preferred solution, given your project's
practice to do cherry-picks and never full merges.]

Michael